There is nevertheless a difference between a machine designed for some particular purpose and a human being singing...
I do agree the Chinese Room argument is rather fallacious (depending on how you view it), but I have come to think over the past couple of years that there's a kind of situatedness to intelligence (in a very broad sense) that does warrant skepticism towards fundamentally behaviorist conjectures such as the Turing test.
In other words, singing is beautiful because it is situated in the context of human experience. It is not just the physical quality of the singer's voice that we respond to, but also (even more so, perhaps), the connection between his voice, the lyrics, and his (perceived) character, i.e. his credibility. This even works in reverse in "machine music", only there we respond to the lack of these qualities, or their exaggeration of same (sped up vocals, pitched down vocals, extreme vibrato, etc).
In so far as machines can elicit this response, that is simply because otherwise we wouldn't even build them. This is in stark contrast to the striking purposelessness of our own existence. If such a fundamental difference makes no difference to the questions of conscience and intelligence, then there can't be much to these concepts to begin with -- but the fact is that I think there is.
glib is incredibly convenient to program in because it has no error handling. Your app just goes boom if something unexpected happens, like a memory allocation failing.
Yeah. Of course that's what most versions of the Linux kernel do as well: when they run out of memory, they just start killing processes, rather than returning NULL (with the wonderful rationale that this would break programs that don't check for malloc errors). You can change that behavior by disabling overcommit, sort of, but it's still a worrying attitude.
Obviously, part of a flawless thought process is ensuring that whatever information you need to complete a project isn't junk.
Even assuming this is at all possible, then that means a programmer has to be able to evaluate the information. That requires expert knowledge. A programmer without that expert knowledge cannot make sound decisions. Ergo, your original statement that good programmers "think clearly" is nonsense. It's experts who think clearly.
Simple. Programmers are forced to think. If you can't think clearly, then your code doesn't work.
Well, yes. If you can't spell, then you won't be able to write a book. But that doesn't mean that anybody who can spell can write a book. Thinking clearly is a necessary, but not a sufficient condition for a programmer.
Programming obviously involves a lot of domain-specific knowledge. You can't write Photoshop without knowing a lot about graphics. You can't write Apache without knowing all the relevant RFC's. You can't write a word processor without knowing about fonts, language, and layout.
Most of the times, code doesn't break because the programmer didn't think clearly, but because he was unaware of the full range of inputs.
A programmer gets daily, if not hourly or minute-by-minute feedback on the quality of his thought process.
You might as well say that programmers get minute-by-minute feedback on the quality of their typing. It is true, but for a skilled programmer, it is largely irrelevant.
The skilled programmer primarily gets feedback on the quality of his model. Yes, the construction of this model requires a a lot of "clear thinking" -- but more than anything it requires correct information.
I for one would be very upset if I heard NASA was wasting bandwidth on publicity photos. That is not what multi-million dollar scientific missions are for.
So what are they for? The advancement of science? But to what end? The betterment of mankind? The thrill of pure knowledge? But then isn't the thrill of a pretty picture just as important?
No, I came to realize that it's unproductive to try and shoehorn all communications into the same system. Remember the first rule of system building: do without one if you can.
For better or worse, most people don't work the way you describe. I like to spend time writing clear and concise emails, but most people don't. What's more, my effort is completely lost on them, and sometimes it even strikes them as pedantic/weird/irrelevant.
Ultimately not top-posting is about not being rude to your recipients. Top posting says, "I'm lazy, and this is easiest way for me to provide context you may or may not need. I don't care that it's less convient to you, my time is more valuable than yours."
This just underscores my point. You have an elaborate system, and you want people to conform. What you need to understand is that they are under no obligation to do so whatsoever.
I used to think top posting was bad. I would go as far as to painstakingly reformat the Outlook mails people were sending me. Sometimes the topic would come up between me and a collegue or friend, and I would explain to them that top posting is bad because it destroys the flow of the discussion, making it harder to follow and less useful.
Over the years, however, I met more and more people, and got a lot more mail, with less and less technical content. It became a hassle to correct all their posts, not to mention to repeat the same arguments over and over again. After a while I found myself top posting, as well.
Not all people think alike, and I came to realize my reasonable, rational arguments mostly just served to control the way other people expressed themselves -- i.e., so that they would express themselves more like myself.
Rules such as "top posting destroys the flow of conversation, yadda yadda yadda" aren't the result of some irrefutable process by which the ideal posting format has been established -- they're the exact opposite: they serve as a starting point to find fault with the way other people choose to communicate.
Well, first of all, why would you want to re-encode in a lossy format? It's already in a format that everybody understands, and it's small enough for portable players. That's the whole point. Store as MP3, and you don't need to re-encode.
you lose information, and then the resulting file will sound worse than the MP3.
You lose information, yes, but that doesn't mean that the sound gets noticeably worse.
However, I don't trust apple/msft not to drop support for mp3 in favor of their own codec-du-jour.
Ahhh. You're running non-free software! Then you must, indeed, take every necessary precaution against the vendors taking your data away from you.
If that sounds like I'm gloating/playing the fool, that's half true. But your remark did serve as an eye opener. It just didn't occur to me. It's been a long time since I've had to consider those kinds of issues.
If a better lossless codec comes along later, all I have to do is batch process them all and save some space. No worries about finding a new original to avoid lossy reencoding.
I doubt it. Most likely, by the time a better codec is in POPULAR use, nobody will be using 16/44.1 CD audio anymore, and you'll be reripping your entire collection from SACD or whatever.
I really don't get these people who prepare for nebulous eventualities that may or may not come to pass some time in the future.
Why not just rip to 256bits/s MP3. Save yourself the time of reencoding your stuff every time you want to take it with you and save many many gigabytes. So what if you lose a few bits. Chances are you'll lose everything in a hard disk crash anyway, between now and a few years time.
There is nothing rational about preparing yourself for an event that is less probable than slipping in the bathroom and breaking your neck.
I don't believe for a second that the "Cog" commercial is for real. Everything about it just reeks of CG. Why? Well, I can't put my finger to it. It's too clean. Surfaces seem odd. The lighting seems unnatural. It just doesn't jive for me. Two shots? I think it's a bald-faced lie.
We've already established that moderate proficiency in a high-level language with a good optimizing compiler is worth far more than mastery of assembly in today's environment
Only if "today's environment" is composed of beige desktop boxes. When programming for embedded systems (say, a mobile phone), a proficient assembly programmer can make the difference between a product that never makes it to market and a product that succeeds wildly.
Deep skills allow companies to save $dollars on each unit shipped. With volume, this saves millions.
Sorry, I don't see what that page is supposed to prove. How about some performance data from Bugzilla (http://bugzilla.mozilla.org/show_bug.cgi?id=11893 3)
They should fix the abysmal DOM performance some time. Simple DHTML applications or even plain document.write() hacks can bring Mozilla to its knees as it labors to add nodes to the document.
Slashdot Mirror
There is nevertheless a difference between a machine designed for some particular purpose and a human being singing...
I do agree the Chinese Room argument is rather fallacious (depending on how you view it), but I have come to think over the past couple of years that there's a kind of situatedness to intelligence (in a very broad sense) that does warrant skepticism towards fundamentally behaviorist conjectures such as the Turing test.
In other words, singing is beautiful because it is situated in the context of human experience. It is not just the physical quality of the singer's voice that we respond to, but also (even more so, perhaps), the connection between his voice, the lyrics, and his (perceived) character, i.e. his credibility. This even works in reverse in "machine music", only there we respond to the lack of these qualities, or their exaggeration of same (sped up vocals, pitched down vocals, extreme vibrato, etc).
In so far as machines can elicit this response, that is simply because otherwise we wouldn't even build them. This is in stark contrast to the striking purposelessness of our own existence. If such a fundamental difference makes no difference to the questions of conscience and intelligence, then there can't be much to these concepts to begin with -- but the fact is that I think there is.
glib is incredibly convenient to program in because it has no error handling. Your app just goes boom if something unexpected happens, like a memory allocation failing.
Yeah. Of course that's what most versions of the Linux kernel do as well: when they run out of memory, they just start killing processes, rather than returning NULL (with the wonderful rationale that this would break programs that don't check for malloc errors). You can change that behavior by disabling overcommit, sort of, but it's still a worrying attitude.
Obviously, part of a flawless thought process is ensuring that whatever information you need to complete a project isn't junk.
Even assuming this is at all possible, then that means a programmer has to be able to evaluate the information. That requires expert knowledge. A programmer without that expert knowledge cannot make sound decisions. Ergo, your original statement that good programmers "think clearly" is nonsense. It's experts who think clearly.
Only when the project at hand requires it. There are an infinite number of projects that don't.
Such as?
The quality of his model depends on the quality of his thought processes, doesn't it?
The thought process can be flawless, but if it's based on incorrect information, then the result will be junk.
Simple. Programmers are forced to think. If you can't think clearly, then your code doesn't work.
Well, yes. If you can't spell, then you won't be able to write a book. But that doesn't mean that anybody who can spell can write a book. Thinking clearly is a necessary, but not a sufficient condition for a programmer.
Programming obviously involves a lot of domain-specific knowledge. You can't write Photoshop without knowing a lot about graphics. You can't write Apache without knowing all the relevant RFC's. You can't write a word processor without knowing about fonts, language, and layout.
Most of the times, code doesn't break because the programmer didn't think clearly, but because he was unaware of the full range of inputs.
A programmer gets daily, if not hourly or minute-by-minute feedback on the quality of his thought process.
You might as well say that programmers get minute-by-minute feedback on the quality of their typing. It is true, but for a skilled programmer, it is largely irrelevant.
The skilled programmer primarily gets feedback on the quality of his model. Yes, the construction of this model requires a a lot of "clear thinking" -- but more than anything it requires correct information.
I for one would be very upset if I heard NASA was wasting bandwidth on publicity photos. That is not what multi-million dollar scientific missions are for.
So what are they for? The advancement of science? But to what end? The betterment of mankind? The thrill of pure knowledge? But then isn't the thrill of a pretty picture just as important?
No, I came to realize that it's unproductive to try and shoehorn all communications into the same system. Remember the first rule of system building: do without one if you can.
I used to think top posting was bad. I would go as far as to painstakingly reformat the Outlook mails people were sending me. Sometimes the topic would come up between me and a collegue or friend, and I would explain to them that top posting is bad because it destroys the flow of the discussion, making it harder to follow and less useful.
Over the years, however, I met more and more people, and got a lot more mail, with less and less technical content. It became a hassle to correct all their posts, not to mention to repeat the same arguments over and over again. After a while I found myself top posting, as well.
Not all people think alike, and I came to realize my reasonable, rational arguments mostly just served to control the way other people expressed themselves -- i.e., so that they would express themselves more like myself.
Rules such as "top posting destroys the flow of conversation, yadda yadda yadda" aren't the result of some irrefutable process by which the ideal posting format has been established -- they're the exact opposite: they serve as a starting point to find fault with the way other people choose to communicate.
The result of the previous extinction level event (if that hypothesis is even correct), was us, which by all accounts is a good thing. So why worry?
Change format every six months? Who?
I'm still using MP3. So is 80% of the rest of the world. Nothing wrong with it.
However if you re-encode in a lossy format
Well, first of all, why would you want to re-encode in a lossy format? It's already in a format that everybody understands, and it's small enough for portable players. That's the whole point. Store as MP3, and you don't need to re-encode.
you lose information, and then the resulting file will sound worse than the MP3.
You lose information, yes, but that doesn't mean that the sound gets noticeably worse.
If you reencode from lossly to lossly you get alot more artifacts and it in general is not a good idea.
.WAV generated from a 256bit MP3 is virtually indistinguishable from the original .WAV. Why store information that serves no purpose?
A
And disk space is cheap.
Unless you run out of it.
Why not just store it as high quality MP3s? Saves a lot of space and hassle.
However, I don't trust apple/msft not to drop support for mp3 in favor of their own codec-du-jour.
Ahhh. You're running non-free software! Then you must, indeed, take every necessary precaution against the vendors taking your data away from you.
If that sounds like I'm gloating/playing the fool, that's half true. But your remark did serve as an eye opener. It just didn't occur to me. It's been a long time since I've had to consider those kinds of issues.
If a better lossless codec comes along later, all I have to do is batch process them all and save some space. No worries about finding a new original to avoid lossy reencoding.
I doubt it. Most likely, by the time a better codec is in POPULAR use, nobody will be using 16/44.1 CD audio anymore, and you'll be reripping your entire collection from SACD or whatever.
I really don't get these people who prepare for nebulous eventualities that may or may not come to pass some time in the future.
Why not just rip to 256bits/s MP3. Save yourself the time of reencoding your stuff every time you want to take it with you and save many many gigabytes. So what if you lose a few bits. Chances are you'll lose everything in a hard disk crash anyway, between now and a few years time.
There is nothing rational about preparing yourself for an event that is less probable than slipping in the bathroom and breaking your neck.
100KB/s upstream is a lot. Be happy with it.
Daryl can have friends buying and selling for him. The money made in that fashion can be siphoned back to him any number of ways.
applications expect both multithreading and lots of bitmap storage from the X server.
What the hell do you mean? That X should be multithreaded? Or reentrant? Or threadsafe? What's wrong with the bitmap storage as it exists today?
That means that a lot of complexity in the existing server is devoted to optimizing things few people still care about.
It _sounds_ reasonable enough, but what evidence is there to support this claim?
Also, I thought the Cog commercial was lifeless and insipid, regardless of any real or perceived CG qualities...
I don't believe for a second that the "Cog" commercial is for real. Everything about it just reeks of CG. Why? Well, I can't put my finger to it. It's too clean. Surfaces seem odd. The lighting seems unnatural. It just doesn't jive for me. Two shots? I think it's a bald-faced lie.
We've already established that moderate proficiency in a high-level language with a good optimizing compiler is worth far more than mastery of assembly in today's environment
Only if "today's environment" is composed of beige desktop boxes. When programming for embedded systems (say, a mobile phone), a proficient assembly programmer can make the difference between a product that never makes it to market and a product that succeeds wildly.
Deep skills allow companies to save $dollars on each unit shipped. With volume, this saves millions.
Enjoyed reading that!
Sorry, I don't see what that page is supposed to prove. How about some performance data from Bugzilla (http://bugzilla.mozilla.org/show_bug.cgi?id=11893 3)
mozilla ie6
getElementById() 985 280
getElementsByTagName() 1230 293
createElement() 1314 235
getAttribute() 465 148
setAttribute() 447 157
Yes; these numbers apply to an old version of Mozilla. Well, so what? The link you supplied only tests Mozilla 1.1.
They should fix the abysmal DOM performance some time. Simple DHTML applications or even plain document.write() hacks can bring Mozilla to its knees as it labors to add nodes to the document.