1. The number of lines of source code in an application may well exceeed ten million, albeit the vast majority of that number being part of libraries, the operating system and so forth. Great engineering comes from *simplifying* the problem, not throwing complexity at it (which, IMHO, is where so many bugs come from today.)
2. Oil rigs and planes are *much* simpler things than large software projects. For a start, physical objects generally behave in well understood ways. You tend not to get strange emergent behaviour from piling bricks on top of one another. More to the point, physical objects do not share state (another major source of bugs.)
3. Pattern recognition is actually harder to get right than correctly implementing a protocol. A key problem with PR is working out exactly what it is your system has learned (cf. the case of the military system that was trained to spot tanks, but instead merely learned the difference between night and day.) PR is also currently very poor at dealing with structured input, which I would have thought would be a major showstopper for any realistic application in software development.
4. I'd argue that it's easier to work harder on getting things right in the first place (and let's face it, software engineering is pretty much a joke at this stage of its evolution) rather than taking on yet another approach about which we understand comparatively very little indeed.
5. Stateful computation and (sorry to say this, but) the woefully inadequate abstraction tools available to today's commercial programmers (and no, OO does not cut it, despite the hype and despite the fact you've been using it for years -- if it did work as advertised, code would be much less buggy) are major contributors to unreliable software systems. Oh, and the fact that any monkey can become a programmer these days.
6. The best programmers often stick around academia because that's where the hardest challenges are taken on. Academic programming language designers (who do have bags of experience in the sort of thing commercial programmers get up to every day) have been advocating declarative languages for decades. For years now the compilers and tools for these languages have been industrial strength. Declarative programming *does* require you to change your way of thinking, but the pay off is programs that are an order of magnitude shorter and very, very often run correctly first time.
This is going to go down like a cup of cold sick in this forum, but here goes anyway...
It is better to need to use the debugger far less than to have an improved debugger.
A large class of bugs that arise in programs written in today's mainstream langauges (C, C++, Java, C#, VB) either simply cannot be expressed or are immediately detected by the compiler if one uses a modern, statically typed declarative language (Mercury, Haskell, SML etc.) The opportunities for run-time errors are far fewer in number.
The experience of many declarative programmers is that 90% of the time, once the compiler has accepted one's program, the program works exactly as intended.
On the other hand, experience with imperative languages indicates that 90% of the time one has to then run the program under the debugger in order to find out how it's going wrong. Time spent debugging often significantly outweighs the time spent coding in the first place.
Declarative languages have other advantages, even if one does have to resort to the debugger. For instance, since computations are generally side-effect free, one can re-run sub-computations without having to worry about affecting any program state. This allows for declarative debuggers, which help automate the process of identifying the point in a program that contains the first bug by remembering correct/incorrect answers from the programmer for each subcomputation of interest.
Finally, since declarative programs tend to be 10-20% of the size of the equivalent imperative program, and they usually don't contain all sorts of tedious bookkeeping code, there are consequently far fewer locations in which a bug can hide.
(For the record, modern compilers for Mercury etc. turn out code that is competitive in speed terms with C++ in most applications, and sometimes better, sometimes worse in others.)
It seems to me that that's the main thrust of Penrose's argument: "Consciousness involves quantum mechanics, and, well, no one really understands quantum mechanics." Unfortunately, for now, he's right.
I think it would be truer to say that no one has yet found an intuitive interpretation of QM. On the other hand, there's no evidence to suggest that QM-level phenomena are significant to the operation of the brain; on the contrary, it's far better to stick to the simpler, macroscopic physical models up to the point where we observe a divergence in behaviour from prediction (if we ever do) and therefore have evidence that a finer-grained model is required.
Another important point is that while Church's thesis remains unproven, nobody has yet come up with a quantum model of computation that is more powerful than the Turing machine. To posit that such a thing might exist to support one's argument is pure speculation.
This is what upset me so much about Penrose' position: nowhere is any evidence presented to back up any of his key arguments. The closest you get to supporting evidence is a claim that human mathematicians are not subject to Goedel's incompleteness theorems. This is either because they are not ideal reasoners (demonstrably the case) or because they are entirely consistent (!), but are operating on principles that are not subject to Goedel.
You must be kidding. Perhaps you just read the conclusion?
Penrose' "The Emperor's New Mind" is a collection of chapters on interesting topics, which have all been addressed far better by other authors also trying to communicate with the layman, each of which ends with an assertion of the form "...and here's a `result', a conving demonstration of which is too large to include in this book." As for the more high powered physics stuff, I can't argue, but for the computation theory and AI philosophy, you could drive busses through the holes.
A major part of the problem is that Penrose simply does not seem to accept Goedel's Incompleteness Theorems. They are theorems, which means they're a fact of life. The correct answer to the observation that human mathematicians have so far been rather good about working around the problem is that human mathematicians are not perfect reasoners and hence are not subject to the Incompleteness Theorems. The down side to this position is that you can't fully trust human mathematics (but there's nothing new there.)
It certainly isn't warranted to suggest that the quantum structure of the brain somehow allows us to violate the laws of logic based upon properties that are neither defined nor observed.
By all accounts Penrose is a first class physicist, but as a philosopher of AI I find him utterly unconvincing.
A suggestion was reported the other day that customers may consider paying 1c for each advertisement that was *not* transmitted to them over their video-on-demand cable channel. This is a smashing idea. I'll happily pay small beer for an advertising-free existence.
I'd like to see the same sort of thing for the web, except the cost per advert should be much lower (e.g. 0.01c/filtered ad.) My ISP would bill me $5/month or whatever, filter out the advertising, and distribute the micropayments to the sites whose advertising had been filtered (one can imagine also placing a cap on the number of adverts a page might try to fit in - I seriously doubt I'm interested in the content of a page that has a double-figure number of ad's.)
I suggested that consumers pay 1 cent per commercial skipped (which is about the same as what advertisers pay).
What a superb idea. I would subscribe to this in an instant. I'd be delighted to pay 30c - 50c/day to the TV companies to show me uninterrupted programming.
Re:Please, Deep Blue is not AI, chess is a limited
on
Behind Deep Blue
·
· Score: 2, Insightful
Sorry, but this post does not show any insight into the problem.
There are two schools of AI: "applied" AI tackles all the problems that conventional engineering hasn't a clue about (which is why "applied" AI fails so often); cognitive science attempts to come up with plausible, implementable explanations for various kinds of cognition (which is why you won't find cognitive scientists tackling applications-level problems.)
I see no reason to argue one way or the other that a sophisticated machine intelligence (i.e. something which most people agreed was "intelligent" after observing it in action) would or would not exhibit behaviours that we might interpret as emotional responses.
To put this in context, I only give other people the benefit of the doubt that they experience consciousness: there is as-yet no way for them to prove they actually are conscious rather than just automata giving a convincing impersonation.
One final point on the topic of awareness: every computer program with finite resources can be reduced to a state machine which can be reduced to a lookup-table and an index into that table. People often get upset that even the fanciest AI program would also be subject to this sort of construction - they spend ages arguing why the lookup table would be a fake (would not be "aware") and the more complex program the real thing. The problem here is that nobody has a handle yet on what constitutes "aware"ness, so it seems to me that until we resolve this one, we have to stick to functionalism: if it looks like a dog and barks like a dog, at least for the time being we might as well call it a dog.
It's rather telling that the first thing you think of in connection with coding discipline is concrete syntax and Python and not, say, strong, powerful type systems, enforced modularity, declarative clarity and so forth.
As for your comment about hiring disciplined programmers, well, it's banal. And yet you present it as though it supported some point against strongly typed languages.
Having written that, I don't know why I'm bothering to reply to you.
Of course, you could always use a real language that enforced coding discipline.
Why do some programmers insist that its more important to be able to lash up buggy code in an eye blink than to write maintainable, bug free code in the first place? Is debugging and maintenance time somehow cheaper?
The MTP cannot be as secure as the OTP. However, it's not obvious to me that its significantly weaker.
A one-time pad is a a sequence of random bits b0..bn.
A plaintext message is a sequence of bits p0..pm with m =< n.
The cyphertext is the sequence of bits c0..cm where ci = pi xor bi.
Since the bi are random, the ci are also random - hence in the absence of the OTP the cyphertext is undecodable.
Important: having decyphered the message, both sender and receiver delete bits b0..bm from their OTPs.
The problem with OTPs is arranging for secure delivery of b0..bn in the first place, without interception.
It seems the poster is suggesting that there is a secure way to use OTPs, without the important step of discarding used bits. This means that bits will be reused according to some function. So in effect the "many time pad" (MTP) is generating a longer stream of "xoring" bits from a b0..bn - that is, the MTP "xoring" bits m0... are constructed according to mi = f(i, b0..bn) - with f presumably being publically available - and the cypher text is given by ci = pi xor mi.
The problem is that for infinitely many i, j, k, f(i, b0..bn) = f(j, b0..bn) = f(k, b0..bn)...
After we have seen enough cyphertext go by (presumably many, many times more than n+1 bits, if f is any good) we will start to learn more and more about b0..bn (xored with some plaintext). Eventually we will collect a library of bits pi xor f(i, b0..bn), pj xor f(j, bo..bn and so forth where we know that f(i, b0..bn) = f(j, b0..bn), hence we can work out pi xor pj. But this is just the xor of two non-random plaintext messages, which is subject to fairly straightforward attack.
So the upshot of it all is that if f is good then you should be able to (significantly) extend the life of your OTP, but eventually you will have to ditch the b0..bn and get some new ones. However, if for, say, n = 10^9 you get a useful lifetime of, say, 10^18 message bits, then you'll be happy with your scheme for a long time!
That said, you still have to solve the key exchange problem, which is the real stopping point with symmetric crypto systems.
I had lasik eye surgery performed by Dr Noel Alpins at the Melbourne NewVision Clinic last January. Before the operation my prescription was -7.5 and -3.5 in my left and right eyes respectively with astigmatism in both. I now have 20/16 vision, which is better than 20/20 - I can read the lowest line on the optician's chart without straining. I can highly recommend this clinic.
The surgery takes about a minute and a half from start to finish, for both eyes. Your eye cannot feel anything during the procedure, all you have to be able to do is look at a little orange dot for about forty five seconds with each eye. After surgery, they tape plastic shields, a bit like large sun-glasses, over your eyes to prevent you from rubbing them. When you come back the next day they remove the shields and give you an eye test. You then have to take eye drops for the next fortnight or so.
Improvement in vision is immediate. The only artefact is that, at first, in situations of high contrast, such as bright lights at night or watching television in a dark room, you will observe some mild haloing (the effect is much less annoying than, say, a fingerprint smudge on your glasses.) The effect diminishes to nothing over the next four to eight weeks.
Risks: I was naturally very concerned about any risk to my eyesight. My prescription was sufficiently strong that I didn't want anything to make it worse. Dr Alpins explained to me that by having worn contact lenses for more than eighteen months (about a decade or so, in fact) I had already exposed my eyes to greater risk than would be the case for undergoing LASIK. The clinic aims to get at least 20/20 vision in each patient; they consider it a failure when somebody has to return three months later for minor corrective work to reach 20/20 (this happens in about 3% of cases, if I recall correctly.)
Finally, you can check Dr Alpins' publication list on the web and verify his claims to have invented a number of improvements to the technique over the last fifteen years that are now in use worldwide.
Going for surgery has had a marvellous effect on my life. It pays for itself every day by removing the hassle of glasses and contacts. It's especially good when you go swimming or clubbing or play sport and so forth. Magic stuff.
The original poster pointed out some flaws in XML (and XML is close to being the worst of all possible worlds) and how easy they would have been to fix.
You point out the advantages of the existence of having a standard (XML) and that there are tools around to help you manipulate the stuff.
Both points of view hold water. But, technically, XML is really rather bad and we are already paying the price for it.
Asking for proof is not unreasonable, nor is it arrogant. In the absence of any evidence to support the existence of a god, why should I believe in one? Physics and mathematics do an excellent job of explaining the world around us.
I would not ask a believer to offer proof, because I do not believe they can possibly do so (those that attempt to make an argument are rather forgetting the nature of faith - that is, belief without evidence.)
The only half-way-convincing line I have heard on this was from an acquaintance who said that his personal experience of God was utterly compelling and completely untransferable to anybody else. Fair enough. I cannot deny my own consciousness, although I've found nothing in science that offers any sort of explanation for the phenomenon. I don't believe consciousness is something mystical, however, but that's probably because I've never found mystical-type "explanations" at all convincing.
Finally, to those who say that their personal philosophy starts with the *axiom* "God exists" are on rather soft ground. Mathematically, I can construct any formal system I like and place any interpretation on the symbols. This doesn't mean that my interpretation or my formal system stand in any sensible correspondence to the real world. Finding working correspondences is the job of physics, but there the association is only supported so long as it is not contradicted by the facts *and* provides some useful predictive power. Without the former constraint, physics would be uselessly inconsistent; without the latter, physics would be encumbered with mountains of nonsense speculation.
Umm, no. What we need is something that allows us to precisely specify (i.e. not UML) the relationship between input and output at an high level of abstraction, in a form that can be automatically turned into an efficient, working program, with the minimum amount of attention paid to language-enforced bookkeeping.
Such things already exist and they are called declarative programming languages (check out Mercury, Haskell, OCaml, ML and so forth.)
(Note that imperative languages fall short of the ideal since the relationship encoded in an imperative program of any size is very hard to identify. This is one of the reasons why they're so difficult to debug.)
Unfortunately no-one has yet come up with a general purpose graphical notation that has the brevity, clarity and precision of mathematical notation. Declarative programming languages come closer to the mark than anything else.
My guess is that no 2D graphical notation will be sufficiently expressive for all but the simplest tasks (check out the work on interaction nets for best effort so far.)
Ah, also check out "Introducing Quantum Theory" from the "Introducing..." series. Don't be put off by the cartoon style - this book is written by someone who really knows their onions. It essentially tells the story of physics from about 1850-1950: the experiments that classical theory couldn't explain, the first use of statistical mechanics and the quantum concept, the attempts to reconcile the quantum approach with the classical approach, and the various problems and their solutions that led to modern quantum theory.
The key results are presented, but you won't know enough to use them. What you will have, however, is a genuine understanding of what it's all about and how we got there.
I want to second this. I studied physics during my first year at Cambridge and my supervisor practically begged me to buy these books. I wish I had taken his advice.
Since graduation (I'm a computer scientist by trade) my interest in physics has been rekindled. I've read all the other books that have been recommended on this topic ("A Brief History of Time", "The Universe in a Nutshell", "The Elegant Universe", and so forth) and found them all immensely frustrating: the first few chapters are straightforward enough thanks to the physics I was exposed to, but after that things become less and less precise and harder and harder to gain even an inkling of what point the author is trying to make. The final chapters of these books might as well be written in Perl, they're so opaque.
The Feynman Lectures not only give you the physics, but also the maths you need to do the physics. Moreover, Feynman does it in such an easy style that you're half way through the book before you realise you now deeply understand the "why" of core bits of maths and physics where before you only just grasped the process of how to apply certain results. Magic stuff.
You've got this so wrong it's hard to know where to start.
Perhaps with an analogy: we should teach physics by starting with quantum mechanics and then climb the abstraction tree until people can understand Newtownian mechanics. Hmm, maybe not.
Assembly language should be taught to communicate a genuine understanding of how a processor works and how the very lowest levels of an OS interact with the hardware. Beyond that, there's not much use for it on a CS course.
Why on Earth you think algorithms are best understood by implementing them in the least abstract, hardest-to-debug language possible is utterly beyond me. About the only thing you might glean from such an undertaking would be an understanding of the huge amount of bookkeeping that goes on behind the scenes. You wouldn't even learn anything particularly useful about the cache performance of your code that you couldn't learn from a suitably (i.e. automatically) instrumented binary generated from an higher level language.
The point of algorithms is that they *are* independent of the underlying language (you did study big-O notation, I take it?), so they should be taught using languages that require the minimum amount of algorithm-irrelevant cruft in order to express the idea. Good grief, would you seriously expect anyone to implement 234-trees or binomial heaps in raw assembler?
Bottom line: if you don't understand *abstraction* then you're going to be a lousy programmer.
I keep ranting about this, but I doubt CS programs are going to change.
That is definitely not true. The tasks are specifically chosen to highlight the unique strengths of functional programming languages, especially compared to imperative languages like C++.
Rubbish. The five contests to date have involved coding a player for a board game, a logic optimizer, a ray tracer, an optimizer for an HTML-like language, and an AI for an "action" game.
I'd lay money on virtually all of the equivalents of these applications out there in commercial-land being written in C/C++ or Java. (One does of course wonder why things persist in being this way...)
The problem with analyzing complex problems in most imperative languages is not that they don't have the libraries that come with most declarative languages, but rather that they just do not provide things like algebraic data types and pattern matching, not to mention any kind of sane support for higher order programming. What the program is trying to do gets buried under all the tedious and error-prone bookkeeping forced on the programmer by the lack of support from the language.
There is a common misconception that declarative programming language designers are solely or primarily interested in writing theorem provers. This might have been true some decades ago, but for a long time the emphasis has been on finding better and more efficient ways of solving everyday programming problems faced by working programmers.
The original experiment has been duplicated, but the results claimed by the original investigator have never been seen since and said original investigator apparently refuses to tell the other experimenters what it is they're doing wrong.
More to the point, relativity says that gravity is not a force, but curvature of spacetime. It checks out to as many decimal places as can be measured. On the other hand, there's no theory that even hints at the gravity defying (i.e. spacetime warping) powers of spinning superconductors.
Occasionally discoveries happen by accident, but the vast, vast, vast majority of progress is made by conducting experiments indicated by theory (to do otherwise is to waste one's time hoping to get lucky.)
I'm reminded of the story about a man found spooning yoghurt into a lake. The onlookers ask him what he's up to and he tells them that this is how he's going to make an entire lake of yoghurt. They tell him that this isn't how yoghurt is made and he replies, "Well, yes, but what if it worked?!"
FIRST, what algorithm is being run is a matter of interpretation (at the end of the day it's a dumb CPU grinding through machine code.) There are infinitely many possible logical interpretations for any given computer program. Just because I as an AI researcher am thinking in terms of predicates, propositions, logical inference and what-have-you, doesn't mean that the program I write to implement all this stuff can't also be viewed as a glorified list processor.
SECOND, any finite state machine (i.e. resource limited digital computing device such as your computer) can be equally well represented using a lookup table. Each possible state has a row and every possible input has a column. The table cells simply say what the next state (or row) the system should move to for a given input.
Any AI program, including an hypothetical simulation of the brain state copied from a real human being, is subject to the same representation. (This is a thought experiment since the size of the table for even a small program would be infeasibly large, but that has nothing to do with the philosophical side of the argument.) Now, why should an AI written in terms of knowledge bases and inference rules etc. be more "real" than one implemented as a state machine or table?
In closing, it seems to me that the real issue here is what is it that produces qualia, the conscious experience of being us? Nobody knows, yet we each claim to have them and give one another the benefit of the doubt that we have qualia, largely only on the basis that we look pretty much alike.
Slashdot Mirror
The man has got many things wrong.
1. The number of lines of source code in an application may well exceeed ten million, albeit the vast majority of that number being part of libraries, the operating system and so forth. Great engineering comes from *simplifying* the problem, not throwing complexity at it (which, IMHO, is where so many bugs come from today.)
2. Oil rigs and planes are *much* simpler things than large software projects. For a start, physical objects generally behave in well understood ways. You tend not to get strange emergent behaviour from piling bricks on top of one another. More to the point, physical objects do not share state (another major source of bugs.)
3. Pattern recognition is actually harder to get right than correctly implementing a protocol. A key problem with PR is working out exactly what it is your system has learned (cf. the case of the military system that was trained to spot tanks, but instead merely learned the difference between night and day.) PR is also currently very poor at dealing with structured input, which I would have thought would be a major showstopper for any realistic application in software development.
4. I'd argue that it's easier to work harder on getting things right in the first place (and let's face it, software engineering is pretty much a joke at this stage of its evolution) rather than taking on yet another approach about which we understand comparatively very little indeed.
5. Stateful computation and (sorry to say this, but) the woefully inadequate abstraction tools available to today's commercial programmers (and no, OO does not cut it, despite the hype and despite the fact you've been using it for years -- if it did work as advertised, code would be much less buggy) are major contributors to unreliable software systems. Oh, and the fact that any monkey can become a programmer these days.
6. The best programmers often stick around academia because that's where the hardest challenges are taken on. Academic programming language designers (who do have bags of experience in the sort of thing commercial programmers get up to every day) have been advocating declarative languages for decades. For years now the compilers and tools for these languages have been industrial strength. Declarative programming *does* require you to change your way of thinking, but the pay off is programs that are an order of magnitude shorter and very, very often run correctly first time.
This is going to go down like a cup of cold sick in this forum, but here goes anyway...
It is better to need to use the debugger far less than to have an improved debugger.
A large class of bugs that arise in programs written in today's mainstream langauges (C, C++, Java, C#, VB) either simply cannot be expressed or are immediately detected by the compiler if one uses a modern, statically typed declarative language (Mercury, Haskell, SML etc.) The opportunities for run-time errors are far fewer in number.
The experience of many declarative programmers is that 90% of the time, once the compiler has accepted one's program, the program works exactly as intended.
On the other hand, experience with imperative languages indicates that 90% of the time one has to then run the program under the debugger in order to find out how it's going wrong. Time spent debugging often significantly outweighs the time spent coding in the first place.
Declarative languages have other advantages, even if one does have to resort to the debugger. For instance, since computations are generally side-effect free, one can re-run sub-computations without having to worry about affecting any program state. This allows for declarative debuggers, which help automate the process of identifying the point in a program that contains the first bug by remembering correct/incorrect answers from the programmer for each subcomputation of interest.
Finally, since declarative programs tend to be 10-20% of the size of the equivalent imperative program, and they usually don't contain all sorts of tedious bookkeeping code, there are consequently far fewer locations in which a bug can hide.
(For the record, modern compilers for Mercury etc. turn out code that is competitive in speed terms with C++ in most applications, and sometimes better, sometimes worse in others.)
I think it would be truer to say that no one has yet found an intuitive interpretation of QM. On the other hand, there's no evidence to suggest that QM-level phenomena are significant to the operation of the brain; on the contrary, it's far better to stick to the simpler, macroscopic physical models up to the point where we observe a divergence in behaviour from prediction (if we ever do) and therefore have evidence that a finer-grained model is required.
Another important point is that while Church's thesis remains unproven, nobody has yet come up with a quantum model of computation that is more powerful than the Turing machine. To posit that such a thing might exist to support one's argument is pure speculation.
This is what upset me so much about Penrose' position: nowhere is any evidence presented to back up any of his key arguments. The closest you get to supporting evidence is a claim that human mathematicians are not subject to Goedel's incompleteness theorems. This is either because they are not ideal reasoners (demonstrably the case) or because they are entirely consistent (!), but are operating on principles that are not subject to Goedel.
...although hunting around on the web you would be forgiven for thinking it should be "Sacks". Type in "Oliver-Sachs Sacks" into Google - amazing.
You must be kidding. Perhaps you just read the conclusion?
Penrose' "The Emperor's New Mind" is a collection of chapters on interesting topics, which have all been addressed far better by other authors also trying to communicate with the layman, each of which ends with an assertion of the form "...and here's a `result', a conving demonstration of which is too large to include in this book." As for the more high powered physics stuff, I can't argue, but for the computation theory and AI philosophy, you could drive busses through the holes.
A major part of the problem is that Penrose simply does not seem to accept Goedel's Incompleteness Theorems. They are theorems, which means they're a fact of life. The correct answer to the observation that human mathematicians have so far been rather good about working around the problem is that human mathematicians are not perfect reasoners and hence are not subject to the Incompleteness Theorems. The down side to this position is that you can't fully trust human mathematics (but there's nothing new there.)
It certainly isn't warranted to suggest that the quantum structure of the brain somehow allows us to violate the laws of logic based upon properties that are neither defined nor observed.
By all accounts Penrose is a first class physicist, but as a philosopher of AI I find him utterly unconvincing.
A suggestion was reported the other day that customers may consider paying 1c for each advertisement that was *not* transmitted to them over their video-on-demand cable channel. This is a smashing idea. I'll happily pay small beer for an advertising-free existence.
I'd like to see the same sort of thing for the web, except the cost per advert should be much lower (e.g. 0.01c/filtered ad.) My ISP would bill me $5/month or whatever, filter out the advertising, and distribute the micropayments to the sites whose advertising had been filtered (one can imagine also
placing a cap on the number of adverts a page might
try to fit in - I seriously doubt I'm interested in the content of a page that has a double-figure number of ad's.)
What a superb idea. I would subscribe to this in an instant. I'd be delighted to pay 30c - 50c/day to the TV companies to show me uninterrupted programming.
Who on Earth moderated this up to zero?
Sorry, but this post does not show any insight into the problem.
There are two schools of AI: "applied" AI tackles all the problems that conventional engineering hasn't a clue about (which is why "applied" AI fails so often); cognitive science attempts to come up with plausible, implementable explanations for various kinds of cognition (which is why you won't find cognitive scientists tackling applications-level problems.)
I see no reason to argue one way or the other that a sophisticated machine intelligence (i.e. something which most people agreed was "intelligent" after observing it in action) would or would not exhibit behaviours that we might interpret as emotional responses.
To put this in context, I only give other people the benefit of the doubt that they experience consciousness: there is as-yet no way for them to prove they actually are conscious rather than just automata giving a convincing impersonation.
One final point on the topic of awareness: every computer program with finite resources can be reduced to a state machine which can be reduced to a lookup-table and an index into that table. People often get upset that even the fanciest AI program would also be subject to this sort of construction - they spend ages arguing why the lookup table would be a fake (would not be "aware") and the more complex program the real thing. The problem here is that nobody has a handle yet on what constitutes "aware"ness, so it seems to me that until we resolve this one, we have to stick to functionalism: if it looks like a dog and barks like a dog, at least for the time being we might as well call it a dog.
It's rather telling that the first thing you think of in connection with coding discipline is concrete syntax and Python and not, say, strong, powerful type systems, enforced modularity, declarative clarity and so forth.
As for your comment about hiring disciplined programmers, well, it's banal. And yet you present it as though it supported some point against strongly typed languages.
Having written that, I don't know why I'm bothering to reply to you.
Of course, you could always use a real language that enforced coding discipline.
Why do some programmers insist that its more important to be able to lash up buggy code in an eye blink than to write maintainable, bug free code in the first place? Is debugging and maintenance time somehow cheaper?
No, just irredemiably bad television.
The MTP cannot be as secure as the OTP. However, it's not obvious to me that its significantly weaker.
A one-time pad is a a sequence of random bits b0..bn.
A plaintext message is a sequence of bits p0..pm with m =< n.
The cyphertext is the sequence of bits c0..cm where ci = pi xor bi.
Since the bi are random, the ci are also random - hence in the absence of the OTP the cyphertext is undecodable.
Important: having decyphered the message, both sender and receiver delete bits b0..bm from their OTPs.
The problem with OTPs is arranging for secure delivery of b0..bn in the first place, without interception.
It seems the poster is suggesting that there is a secure way to use OTPs, without the important step of discarding used bits. This means that bits will be reused according to some function. So in effect the "many time pad" (MTP) is generating a longer stream of "xoring" bits from a b0..bn - that is, the MTP "xoring" bits m0... are constructed according to mi = f(i, b0..bn) - with f presumably being publically available - and the cypher text is given by ci = pi xor mi.
The problem is that for infinitely many i, j, k, f(i, b0..bn) = f(j, b0..bn) = f(k, b0..bn)...
After we have seen enough cyphertext go by (presumably many, many times more than n+1 bits, if f is any good) we will start to learn more and more about b0..bn (xored with some plaintext). Eventually we will collect a library of bits
pi xor f(i, b0..bn), pj xor f(j, bo..bn and so forth where we know that f(i, b0..bn) = f(j, b0..bn), hence we can work out pi xor pj. But this is just the xor of two non-random plaintext messages, which is subject to fairly straightforward attack.
So the upshot of it all is that if f is good then you should be able to (significantly) extend the life of your OTP, but eventually you will have to ditch the b0..bn and get some new ones. However, if for, say, n = 10^9 you get a useful lifetime of, say, 10^18 message bits, then you'll be happy with your scheme for a long time!
That said, you still have to solve the key exchange problem, which is the real stopping point with symmetric crypto systems.
I had lasik eye surgery performed by Dr Noel Alpins at the Melbourne NewVision Clinic last January. Before the operation my prescription was -7.5 and -3.5 in my left and right eyes respectively with astigmatism in both. I now have 20/16 vision, which is better than 20/20 - I can read the lowest line on the optician's chart without straining. I can highly recommend this clinic.
The surgery takes about a minute and a half from start to finish, for both eyes. Your eye cannot feel anything during the procedure, all you have to be able to do is look at a little orange dot for about forty five seconds with each eye. After surgery, they tape plastic shields, a bit like large sun-glasses, over your eyes to prevent you from rubbing them. When you come back the next day they remove the shields and give you an eye test. You then have to take eye drops for the next fortnight or so.
Improvement in vision is immediate. The only artefact is that, at first, in situations of high contrast, such as bright lights at night or watching television in a dark room, you will observe some mild haloing (the effect is much less annoying than, say, a fingerprint smudge on your glasses.) The effect diminishes to nothing over the next four to eight weeks.
Risks: I was naturally very concerned about any risk to my eyesight. My prescription was sufficiently strong that I didn't want anything to make it worse. Dr Alpins explained to me that by having worn contact lenses for more than eighteen months (about a decade or so, in fact) I had already exposed my eyes to greater risk than would be the case for undergoing LASIK. The clinic aims to get at least 20/20 vision in each patient; they consider it a failure when somebody has to return three months later for minor corrective work to reach 20/20 (this happens in about 3% of cases, if I recall correctly.)
Finally, you can check Dr Alpins' publication list on the web and verify his claims to have invented a number of improvements to the technique over the last fifteen years that are now in use worldwide.
Going for surgery has had a marvellous effect on my life. It pays for itself every day by removing the hassle of glasses and contacts. It's especially good when you go swimming or clubbing or play sport and so forth. Magic stuff.
I think you are arguing at cross purposes.
The original poster pointed out some flaws in XML (and XML is close to being the worst of all possible worlds) and how easy they would have been to fix.
You point out the advantages of the existence of having a standard (XML) and that there are tools around to help you manipulate the stuff.
Both points of view hold water. But, technically, XML is really rather bad and we are already paying the price for it.
Asking for proof is not unreasonable, nor is it arrogant. In the absence of any evidence to support the existence of a god, why should I believe in one? Physics and mathematics do an excellent job of explaining the world around us.
I would not ask a believer to offer proof, because I do not believe they can possibly do so (those that attempt to make an argument are rather forgetting the nature of faith - that is, belief without evidence.)
The only half-way-convincing line I have heard on this was from an acquaintance who said that his personal experience of God was utterly compelling and completely untransferable to anybody else. Fair enough. I cannot deny my own consciousness, although I've found nothing in science that offers any sort of explanation for the phenomenon. I don't believe consciousness is something mystical, however, but that's probably because I've never found mystical-type "explanations" at all convincing.
Finally, to those who say that their personal philosophy starts with the *axiom* "God exists" are on rather soft ground. Mathematically, I can construct any formal system I like and place any interpretation on the symbols. This doesn't mean that my interpretation or my formal system stand in any sensible correspondence to the real world. Finding working correspondences is the job of physics, but there the association is only supported so long as it is not contradicted by the facts *and* provides some useful predictive power. Without the former constraint, physics would be uselessly inconsistent; without the latter, physics would be encumbered with mountains of nonsense speculation.
Umm, no. What we need is something that allows us to precisely specify (i.e. not UML) the relationship between input and output at an high level of abstraction, in a form that can be automatically turned into an efficient, working program, with the minimum amount of attention paid to language-enforced bookkeeping.
Such things already exist and they are called declarative programming languages (check out Mercury, Haskell, OCaml, ML and so forth.)
(Note that imperative languages fall short of the ideal since the relationship encoded in an imperative program of any size is very hard to identify. This is one of the reasons why they're so difficult to debug.)
Unfortunately no-one has yet come up with a general purpose graphical notation that has the brevity, clarity and precision of mathematical notation. Declarative programming languages come closer to the mark than anything else.
My guess is that no 2D graphical notation will be sufficiently expressive for all but the simplest tasks (check out the work on interaction nets for best effort so far.)
Ah, also check out "Introducing Quantum Theory" from the "Introducing..." series. Don't be put off by the cartoon style - this book is written by someone who really knows their onions. It essentially tells the story of physics from about 1850-1950: the experiments that classical theory couldn't explain, the first use of statistical mechanics and the quantum concept, the attempts to reconcile the quantum approach with the classical approach, and the various problems and their solutions that led to modern quantum theory.
The key results are presented, but you won't know enough to use them. What you will have, however, is a genuine understanding of what it's all about and how we got there.
Highly recommended.
I want to second this. I studied physics during my first year at Cambridge and my supervisor practically begged me to buy these books. I wish I had taken his advice.
Since graduation (I'm a computer scientist by trade) my interest in physics has been rekindled. I've read all the other books that have been recommended on this topic ("A Brief History of Time", "The Universe in a Nutshell", "The Elegant Universe", and so forth) and found them all immensely frustrating: the first few chapters are straightforward enough thanks to the physics I was exposed to, but after that things become less and less precise and harder and harder to gain even an inkling of what point the author is trying to make. The final chapters of these books might as well be written in Perl, they're so opaque.
The Feynman Lectures not only give you the physics, but also the maths you need to do the physics. Moreover, Feynman does it in such an easy style that you're half way through the book before you realise you now deeply understand the "why" of core bits of maths and physics where before you only just grasped the process of how to apply certain results. Magic stuff.
- Ralph
You've got this so wrong it's hard to know where to start.
Perhaps with an analogy: we should teach physics by starting with quantum mechanics and then climb the abstraction tree until people can understand Newtownian mechanics. Hmm, maybe not.
Assembly language should be taught to communicate a genuine understanding of how a processor works and how the very lowest levels of an OS interact with the hardware. Beyond that, there's not much use for it on a CS course.
Why on Earth you think algorithms are best understood by implementing them in the least abstract, hardest-to-debug language possible is utterly beyond me. About the only thing you might glean from such an undertaking would be an understanding of the huge amount of bookkeeping that goes on behind the scenes. You wouldn't even learn anything particularly useful about the cache performance of your code that you couldn't learn from a suitably (i.e. automatically) instrumented binary generated from an higher level language.
The point of algorithms is that they *are* independent of the underlying language (you did study big-O notation, I take it?), so they should be taught using languages that require the minimum amount of algorithm-irrelevant cruft in order to express the idea. Good grief, would you seriously expect anyone to implement 234-trees or binomial heaps in raw assembler?
Bottom line: if you don't understand *abstraction* then you're going to be a lousy programmer.
I keep ranting about this, but I doubt CS programs are going to change.
That is definitely not true. The tasks are specifically chosen to highlight the unique strengths of functional programming languages, especially compared to imperative languages like C++.
Rubbish. The five contests to date have involved coding a player for a board game, a logic optimizer, a ray tracer, an optimizer for an HTML-like language, and an AI for an "action" game.
I'd lay money on virtually all of the equivalents of these applications out there in commercial-land being written in C/C++ or Java. (One does of course wonder why things persist in being this way...)
The problem with analyzing complex problems in most imperative languages is not that they don't have the libraries that come with most declarative languages, but rather that they just do not provide things like algebraic data types and pattern matching, not to mention any kind of sane support for higher order programming. What the program is trying to do gets buried under all the tedious and error-prone bookkeeping forced on the programmer by the lack of support from the language.
There is a common misconception that declarative programming language designers are solely or primarily interested in writing theorem provers. This might have been true some decades ago, but for a long time the emphasis has been on finding better and more efficient ways of solving everyday programming problems faced by working programmers.
Er, no.
The original experiment has been duplicated, but the results claimed by the original investigator have never been seen since and said original investigator apparently refuses to tell the other experimenters what it is they're doing wrong.
More to the point, relativity says that gravity is not a force, but curvature of spacetime. It checks out to as many decimal places as can be measured. On the other hand, there's no theory that even hints at the gravity defying (i.e. spacetime warping) powers of spinning superconductors.
Occasionally discoveries happen by accident, but the vast, vast, vast majority of progress is made by conducting experiments indicated by theory (to do otherwise is to waste one's time hoping to get lucky.)
I'm reminded of the story about a man found spooning yoghurt into a lake. The onlookers ask him what he's up to and he tells them that this is how he's going to make an entire lake of yoghurt. They tell him that this isn't how yoghurt is made and he replies, "Well, yes, but what if it worked?!"
DEC did release Alpha with their mx binary translation tool (there were versions to convert from Vax and MIPS to alpha, IIRC).
Worked very nicely (i.e. you just pointed it at the binary and it churned out the translation, you hardly needed the man page.)
That the parent comment was awarded a score of four beggars belief.
Good grief, one doesn't even need a back of the envelope sketch to realise that none of the "points" raised merit a minute's thought.
Truly stunning...
Two things.
FIRST, what algorithm is being run is a matter of interpretation (at the end of the day it's a dumb CPU grinding through machine code.) There are infinitely many possible logical interpretations for any given computer program. Just because I as an AI researcher am thinking in terms of predicates, propositions, logical inference and what-have-you, doesn't mean that the program I write to implement all this stuff can't also be viewed as a glorified list processor.
SECOND, any finite state machine (i.e. resource limited digital computing device such as your computer) can be equally well represented using a lookup table. Each possible state has a row and every possible input has a column. The table cells simply say what the next state (or row) the system should move to for a given input.
Any AI program, including an hypothetical simulation of the brain state copied from a real human being, is subject to the same representation. (This is a thought experiment since the size of the table for even a small program would be infeasibly large, but that has nothing to do with the philosophical side of the argument.) Now, why should an AI written in terms of knowledge bases and inference rules etc. be more "real" than one implemented as a state machine or table?
In closing, it seems to me that the real issue here is what is it that produces qualia, the conscious experience of being us? Nobody knows, yet we each claim to have them and give one another the benefit of the doubt that we have qualia, largely only on the basis that we look pretty much alike.
Deep stuff.