Nothing needed, or needs, to be undone. Under all of the legally conducted counts and recounts the winner was George Bush. Subsequent analysis, which some had anticipated would provide evidence that Al Gore should have won, has actually added further evidence that the legal decision almost certainly had no effect on the outcome of the election and that George Bush was the choice of a majority of voters in Florida. It may be unpalatable, but that is the way it is.
If the Court majority had been truly concerned about the equal protection of all voters, the real equal protection violation, of course, took place when they cut off the counting of the undervotes. As indicated, that very act denied the 50 million Americans who voted for Gore the right to have their votes count at all. It misses the point to argue that the five Justices stole the election only if it turns out that Gore overcame Bush's lead in the undervote recount. We're talking about the moral and ethical culpability of these Justices, and when you do that, the bell was rung at the moment they engaged in their conduct. What happened thereafter cannot unring the bell and is therefore irrelevant. To judge these Justices by the final result rather than by their intentions at the time of their conduct would be like exonerating one who shoots to kill if the bullet misses the victim. With that type of extravagant reasoning, if the bullet goes on and accidentally strikes down a third party who is about to kill another, perhaps the gunman should ultimately be viewed as a hero.
Imagine that, law professors disagreeing with a SCOTUS ruling. Boy, how unusual. Cause lawprofessors are so much more objective than the rest of us when it comes to politics.
This was a Supreme Court case. Politics were not supposed to enter into it. Are you implying Bush vs. Gore was a political decision?
That's a good point; I spoke too quickly. Let's see... Kennedy, O'Connor, Scalia, Thomas, and Rehnquist... that comes to a mere 230 years. My bad. I'm pretty sure 230 years of judicial experience outweighs one dumbass with an Internet account.
Rehnquist, Kennedy, O'Connor, Scalia, and Thomas are the very same five traitors who disgraced themselves by rendering the majority opinion in Bush vs. Gore- a ruling which was denounced by 673 law professors and has generally been considered by most observers to be one of the most disgraceful decisions the Supreme Court has ever made.
And let's not overlook the 184 years of judicial experience that rendered the minority opinion in this case, as if it's a "judicial experience" contest entirely between an Anonymous Coward and the five douchebags who foisted this tragedy on us today.
I want a browser that sets all unassigned parameters to random default values.
In Explorer and Opera, you can add JavaScript to your user style sheet. This technique is used by at least one malware program that sets the default style sheet to point to a CSS file that it drops on your hard drive. The CSS file contains JavaScript that monitors you as you surf porn sites or whatever:
The devious thing about this exploit was that the user style sheet the malware stuck on my computer contained CSS property values computed using Microsoft's proprietary expression feature for dynamically computing property values. Specifically, within an expression giving the value of some attribute for the BODY tag, it was looking up certain keywords within the META tag, and if it found them created a pop-up window which took over the entire screen!
So if you use IE, you should be able to implement this "random background color" feature easily in JavaScript by writing a CSS file and using it as your default user stylesheet. Hooray for Microsoft!
That was in response to the original "car" analogy, which was formulated slightly differently from yours. Cars really don't make good analogies because this sort of thing really isn't a problem with cars. People aren't usually trying to cause you harm in your car, and nobody is writing self-replicating cars that reproduce on their own by exploiting manufacturing defects.
I think you may be conflating two events into one- the publishing of a vulnerability and the release of the patch for it. One does not necessarily depend on the other, and they each have different implications for unpatched systems (whether they'll have the patch applied or not).
When a patch comes out for software, it doesn't make the software "suddenly" less secure than it was the day before.
Of course not. That happens when the vulnerability is published, not when the patch is released. They're two separate events.
If you buy a car that explodes when it is hit from the side and the next year the manufacturer releases a new model minus this magic exploding "exploit", your car is similarly not any LESS safe than it was before. It's just relatively less safe when compared to the car that doesn't explode so easily.
Of course it's less safe than it was before! Now all your enemies know they can easily kill you by hitting your car on the side!
Could you self contradisct yourself some more please.....using your logic, a safer car comes out and the old one is more unsafe...but if it's furniture..it doesn't become more unsafe?
No, I said the old one does NOT become more unsafe, and the same applies to furniture. I think you misread something.
If I have a system with a security vulnerability it is unsafe. If everyone knows about it it is very unsafe.
If only Dmitri Hackforprofit and his buddies know about it, I'm toast.
Just because the bad guys exploit holes found by the good guys doesn't mean they don't know how to find them on their own.
This would be a good point if the publish and patch system were finding most or almost all vulnerabilities that exist in software. But we are effectively finding and publishing information about only a very small fraction of existing vulnerabilities. The publishing of that small fraction really doesn't protect you from Dmitri at all. And it lowers the skillset required of script kiddies to wreak havoc.
Ahh, but the in actuality the car was really unsafe the begin with, it's just that no one knew about it.
Your language is obscuring your logic. A car is "safe" or "unsafe". But a software vulnerability is unsafe when nobody knows about it and extremely unsafe when everyone does. Not like cars.
People put down security by obscurity all the time, with anecdotes of how it can't be relied upon, etc., without realizing what a security catastrophe it would be if all the obscurity in the world were to vanish. While it isn't a good idea to be relying on security by obscurity, the fact is that much of the world in fact does rely on obscurity, and going out of our way to destroy obscurity isn't necessarily a good idea either.
That's like saying that we shouldn't produce safer cars because everyone doesn't buy one.
No. Your analogy is flawed.
If cars worked like exploits and patches, then every time a safer car came out, your car would suddenly become less safe than it had been yesterday- and it would become incumbent upon you to get it fixed. Cars, being physical objects, do not behave this way.
And hell, why train drivers, because, you know, crappy drivers are everywhere. Or like saying we shouldn't make furniture fireproof, because, you know, something else will burn.
All these analogies are flawed because they miss the point. When safer drivers are trained, existing drivers don't suddenly become more liable to be in accidents. When safer furniture comes out, the furniture in your living room does not suddenly develop an odor of gasoline.
Of course, it completely disregards those of us who routinely patch our managed systems and keep them dead secure, compatibility and testing be damned.
I think it acknowledges us, but for the minority that we are. The existence on the Internet of a large number of systems remaining unpatched to published vulnerabilities is exactly the nightmare scenario everyone wants to avoid- and suggests that the publish and patch system is broken. People don't patch.
This is DMCA logic. If we criminalize software holes, only criminals will know of exploits. See the problem?
There's a big difference between "criminalizing software holes" and voluntarily agreeing not to publish exploit code. And the way that sentence is worded is extremely misleading. It suggests that if the exploits aren't published then all criminals will still have unfettered access and that isn't true. While it is true that some of the people left who know of the exploits will be criminals, most criminals will no longer know of the exploits because they aren't published and require hard work to discover. Criminals are free even now to ignore the published vulnerabilities and look for unknown ones to exploit. Few choose to do so because it's a lot of work and most of them are lazy and stupid. Not publishing the exploits would force them to always develop this way.
It comes down to this- you can either have 100% of machines unpatched to N unknown vulnerabilities, or you can have 100% unpatched to N-m unknown vulnerabilities and 50% patched to m published vulnerabilities. Even if you do publish and patch, there are still apparently an unlimited numer of unknown vulnerabilities in software. They become much more dangerous and easy to exploit once they're published, and not everyone patches. Even if you do patch, unpatched machines on the network still affect you.
Do you think that all comments posted to this story on Slashdot were fairly moderated?
"Soon you and your posts will disappear." -guy on FreeRepublic
Re:Perhaps you'd like another Windows Key
on
Is Caps Lock Dead?
·
· Score: 1
You're applying the wrong standard.
When removing a feature from a product, the question isn't whether users will survive. You have to ask whether they'll be pissed off enough to seek an alternative.
I exaggerated the pain only to illustrate how ticked off I would be, and that I would not purchase a keyboard with no CAPS LOCK key.
Doesn't the term "Darknet" also refer to a collection of networks and other technologies that enable people to share files with little or no fear of detection?
Yes, that's a usage I've seen too, for example in this article in Slate.
I don't look at the keyboard at all when I type. But it's pretty easy to see the green CAPS LOCK light in my peripheral vision, and that's enough feedback to tell whether it's on or off.
WHAT'S THE MATTER WITH YOU PEOPLE?
on
Is Caps Lock Dead?
·
· Score: 2, Insightful
And do you give your constants names so long that you really need to use your caps lock key instead of just using shift?
Of course I do. Don't you?
Either your code is full of single-letter names, or you don't do much programming. Holding down Shift while typing hurts my fingers if I do it too much. If I didn't have CAPS LOCK I'd be on workers' comp by now.
Perhaps you'd like another Windows Key
on
Is Caps Lock Dead?
·
· Score: 2, Interesting
The caps lock key *is* useful, but it is more trouble than it is worth. Do you know what the #1 tech support answer for everything is?
I see no reason why something that is useful to me in my everyday work should be removed just because some idiots call tech support before checking CAPS LOCK when typing passwords.
You realize, of course, that if CAPS LOCK goes, they'll replace it with ANOTHER WINDOWS KEY. My boss at work has a keyboard designed by a demon- there are FOUR WINDOWS KEYS on it. There are the two in the "standard" places, and two more under Insert and Page Down. It's a damn minefield of Windows keys, each one waiting to steal input focus from the current application. Every time I use his keyboard I hit one by mistake. (He hates it too, but hasn't bothered to get a new one since his typing skills have adapted to the hostile keyboard environment.)
Productivity in the US may increase by 10% if we got rid of the stupid thing. If you *need* to type in all caps, pick a menu-option in your word processor or other application.
I doubt your productivity estimate, and I use CAPS LOCK in many different applications. I see no reason why I should have to go around figuring out how to set up macros and key bindings in every application I use just so an AOL call center in Bangalore can lower its call volume.
I might add that I used CAPS LOCK six times so far just while typing this post, and if I didn't have one my finger would be aching by now.
I suspect in the majority of systems, the main-line (without exceptions) is tested/debugged pretty well, while the exception-lines with about ten times the complexity get about one tenth the attention.
That's why checked exceptions don't work in practice. They're great in theory but they run afoul of human nature. People want to get the main line working, and the compiler keeps giving them trouble about the exceptions. So they write catch blocks that swallow them so they can compile, and then they forget about them.
Someone at work wrote a cancellation mechanism that relied on Thread.interrupt(). This is another bad idea in Java, and it was even meant to be used to support cancellation mechanisms. In this case you'd click a Cancel or Stop button, and it would call interrupt() on the thread, setting its interrupt flag. The thread would periodically check its flag with isInterrupted() and finish up immediately if it was set.
That worked great until the thread found its way into code that routinely swallowed InterruptedExceptions. By design in Java, all blocking calls like wait() or sleep() are declared as throwing them, because someone might call interrupt() on a thread while it's blocked. And people immediately swallow them because they're usually an annoyance at the level you're working at when you're using wait() or sleep(). But since the designers of Java figured the exception handling code would be handling things, the interrupt flag isn't set in the case of an InterruptedException. So the Cancel and Stop buttons stopped working, because whenever you clicked on one, you were likely to catch the thread blocked on some low-level sleep() and its catch block would swallow the exception. (The culprit turned out to be the progress bar, which had a 2 millisecond sleep() somewhere in its paint routine.) To fix it, someone had to go around to all those empty catch blocks (all 10,000 of them) and have the current thread re-interrupt itself in each one.
Well that depends on what the exception handler did with the exception doesn't it? I doubt it got the graceful recovery that was waiting inside the if block. I think in this case it did a printStackTrace() and continued on its merry little way, leaving the user puzzled about what was going on.
It's not commonly known that many of the American founding fathers were libertarian computer consultants chafing at high tax brackets from England. In fact, Alexander Hamilton himself often spent weekends dispensing toy plastic muskets to inner city ragamuffins. And the foundations of libertarian thought are written right into the preamble to the Constitution:
"We the People of the United States, in Order to form a more perfect Union, establish Justice, insure domestic Tranquility, provide for the common defence, promote the general Welfare, and secure the Blessings of Liberty to ourselves and our Posterity, do ordain and establish this Constitution for the United States of America."
If that doesn't say "every man for himself" I don't know what does.
It was probably a bad example to use here, since it's not a computer newbie mistake, it's just a new-to-Java mistake. The guy who wrote it had a PhD from Stanford in math which is what made it funny when I came across it a few days ago.
The new operator is guaranteed to never evaluate to null in Java. If a TCP connection can't be made, the Socket constructor will throw an exception and you won't get to the next line at all. This is different from C++ where new evaluates to NULL to indicate failure.
The PHP and JSP are Turing complete. The resulting HTML is not- it's output.
Still, whether or not HTML is Turing complete is irrelevant. If you look at the mistakes that most beginning programmers make, it's that they have no understanding of the human-machine interface. They don't know how to communicate their intentions into forms that computers can understand.
People are used to conversing with people, not computers. Telling people what to do is much different than telling a computer what to do.
First of all computers have no common sense, and a human being has a variable amount of common sense that can be depended upon. So beginners write code like this, relying on the computer's common sense to fix it for them:
begin
readln("Number of Apples", apples);
readln("Number of Carrots", carrots);
readln("Price for 1 Apple", a_price);
readln("Price for 1 Carrot", c_price);
writeln("Total for Apples", a_total);
writeln("Total for Carrots", c_total);
writeln("Total", total);
total:= a_total + c_total;
a_total:= apples * a_price;
c_total:= carrots + c_price; end;
"It's logical what the right solution is, and the computer should reorder the instructions the right way."
Computers are infallible in certain ways that humans aren't, and this confuses people too. You see stuff like this from beginning programmers: let x=0; let x=0;
Why is it repeated? "In case it didn't get it right the first time". I actually found this in someone's old Java code: Socket s = new Socket(ADDR, PORT); if (s==null) { //show error message... }
Turing completeness really isn't what's important. The more fundamental skill is learning how to think when giving instructions to a machine, and for that, HTML is fine for a beginner. HTML will at least teach you that the browser won't read your mind, will encourage you to learn to fix problems by experimenting, and puts you in the correct frame of mind to realize that you will get exactly what you specify and nothing more.
And even if it turns out to be a passing interest, HTML is an extremely useful computer skill to have. And an understanding of HTML is pivotal to many real-world tasks in real programming languages, since HTML is such a common type of data to be parsed and generated by computer programs. I'd say if a terrified adult doesn't know HTML, that should be the first thing they should study.
Slashdot Mirror
Meanwhile, Ray Bradbury is demanding an apology from Microsoft for lifting the title from his classic work I Sing the Body Electric.
At the end of the day you shouldn't let this worry you too much since it didn't change the outcome of the election.
They rang the bell with their actions on the day of their ruling. Subsequent events cannot unring it for them.
1 m * (100 cm/m) * (1 in/2.54 cm) = 39.37007874 in
Look at me, I'm Informative!
Imagine that, law professors disagreeing with a SCOTUS ruling. Boy, how unusual. Cause lawprofessors are so much more objective than the rest of us when it comes to politics.
This was a Supreme Court case. Politics were not supposed to enter into it. Are you implying Bush vs. Gore was a political decision?
That's a good point; I spoke too quickly. Let's see... Kennedy, O'Connor, Scalia, Thomas, and Rehnquist... that comes to a mere 230 years. My bad.
I'm pretty sure 230 years of judicial experience outweighs one dumbass with an Internet account.
Rehnquist, Kennedy, O'Connor, Scalia, and Thomas are the very same five traitors who disgraced themselves by rendering the majority opinion in Bush vs. Gore- a ruling which was denounced by 673 law professors and has generally been considered by most observers to be one of the most disgraceful decisions the Supreme Court has ever made.
And let's not overlook the 184 years of judicial experience that rendered the minority opinion in this case, as if it's a "judicial experience" contest entirely between an Anonymous Coward and the five douchebags who foisted this tragedy on us today.
In Explorer and Opera, you can add JavaScript to your user style sheet. This technique is used by at least one malware program that sets the default style sheet to point to a CSS file that it drops on your hard drive. The CSS file contains JavaScript that monitors you as you surf porn sites or whatever:
So if you use IE, you should be able to implement this "random background color" feature easily in JavaScript by writing a CSS file and using it as your default user stylesheet. Hooray for Microsoft!
That was in response to the original "car" analogy, which was formulated slightly differently from yours. Cars really don't make good analogies because this sort of thing really isn't a problem with cars. People aren't usually trying to cause you harm in your car, and nobody is writing self-replicating cars that reproduce on their own by exploiting manufacturing defects.
I think you may be conflating two events into one- the publishing of a vulnerability and the release of the patch for it. One does not necessarily depend on the other, and they each have different implications for unpatched systems (whether they'll have the patch applied or not).
When a patch comes out for software, it doesn't make the software "suddenly" less secure than it was the day before.
Of course not. That happens when the vulnerability is published, not when the patch is released. They're two separate events.
If you buy a car that explodes when it is hit from the side and the next year the manufacturer releases a new model minus this magic exploding "exploit", your car is similarly not any LESS safe than it was before. It's just relatively less safe when compared to the car that doesn't explode so easily.
Of course it's less safe than it was before! Now all your enemies know they can easily kill you by hitting your car on the side!
Could you self contradisct yourself some more please.....using your logic, a safer car comes out and the old one is more unsafe...but if it's furniture..it doesn't become more unsafe?
No, I said the old one does NOT become more unsafe, and the same applies to furniture. I think you misread something.
I think finding exploits (as a white hat) is obviously a good idea. I'm just not sure that it's a good idea to be publishing them.
Of course, information "wants to be free" and all that.
If I have a system with a security vulnerability it is unsafe. If everyone knows about it it is very unsafe.
If only Dmitri Hackforprofit and his buddies know about it, I'm toast.
Just because the bad guys exploit holes found by the good guys doesn't mean they don't know how to find them on their own.
This would be a good point if the publish and patch system were finding most or almost all vulnerabilities that exist in software. But we are effectively finding and publishing information about only a very small fraction of existing vulnerabilities. The publishing of that small fraction really doesn't protect you from Dmitri at all. And it lowers the skillset required of script kiddies to wreak havoc.
Ahh, but the in actuality the car was really unsafe the begin with, it's just that no one knew about it.
Your language is obscuring your logic. A car is "safe" or "unsafe". But a software vulnerability is unsafe when nobody knows about it and extremely unsafe when everyone does. Not like cars.
People put down security by obscurity all the time, with anecdotes of how it can't be relied upon, etc., without realizing what a security catastrophe it would be if all the obscurity in the world were to vanish. While it isn't a good idea to be relying on security by obscurity, the fact is that much of the world in fact does rely on obscurity, and going out of our way to destroy obscurity isn't necessarily a good idea either.
That's like saying that we shouldn't produce safer cars because everyone doesn't buy one.
No. Your analogy is flawed.
If cars worked like exploits and patches, then every time a safer car came out, your car would suddenly become less safe than it had been yesterday- and it would become incumbent upon you to get it fixed. Cars, being physical objects, do not behave this way.
And hell, why train drivers, because, you know, crappy drivers are everywhere. Or like saying we shouldn't make furniture fireproof, because, you know, something else will burn.
All these analogies are flawed because they miss the point. When safer drivers are trained, existing drivers don't suddenly become more liable to be in accidents. When safer furniture comes out, the furniture in your living room does not suddenly develop an odor of gasoline.
Of course, it completely disregards those of us who routinely patch our managed systems and keep them dead secure, compatibility and testing be damned.
I think it acknowledges us, but for the minority that we are. The existence on the Internet of a large number of systems remaining unpatched to published vulnerabilities is exactly the nightmare scenario everyone wants to avoid- and suggests that the publish and patch system is broken. People don't patch.
This is DMCA logic. If we criminalize software holes, only criminals will know of exploits. See the problem?
There's a big difference between "criminalizing software holes" and voluntarily agreeing not to publish exploit code. And the way that sentence is worded is extremely misleading. It suggests that if the exploits aren't published then all criminals will still have unfettered access and that isn't true. While it is true that some of the people left who know of the exploits will be criminals, most criminals will no longer know of the exploits because they aren't published and require hard work to discover. Criminals are free even now to ignore the published vulnerabilities and look for unknown ones to exploit. Few choose to do so because it's a lot of work and most of them are lazy and stupid. Not publishing the exploits would force them to always develop this way.
It comes down to this- you can either have 100% of machines unpatched to N unknown vulnerabilities, or you can have 100% unpatched to N-m unknown vulnerabilities and 50% patched to m published vulnerabilities. Even if you do publish and patch, there are still apparently an unlimited numer of unknown vulnerabilities in software. They become much more dangerous and easy to exploit once they're published, and not everyone patches. Even if you do patch, unpatched machines on the network still affect you.
Do you think that all comments posted to this story on Slashdot were fairly moderated?
"Soon you and your posts will disappear." -guy on FreeRepublic
You're applying the wrong standard.
When removing a feature from a product, the question isn't whether users will survive. You have to ask whether they'll be pissed off enough to seek an alternative.
I exaggerated the pain only to illustrate how ticked off I would be, and that I would not purchase a keyboard with no CAPS LOCK key.
Doesn't the term "Darknet" also refer to a collection of networks and other technologies that enable people to share files with little or no fear of detection?
Yes, that's a usage I've seen too, for example in this article in Slate.
You look at the keyboard when you type?
I don't look at the keyboard at all when I type. But it's pretty easy to see the green CAPS LOCK light in my peripheral vision, and that's enough feedback to tell whether it's on or off.
And do you give your constants names so long that you really need to use your caps lock key instead of just using shift?
Of course I do. Don't you?
Either your code is full of single-letter names, or you don't do much programming. Holding down Shift while typing hurts my fingers if I do it too much. If I didn't have CAPS LOCK I'd be on workers' comp by now.
The caps lock key *is* useful, but it is more trouble than it is worth. Do you know what the #1 tech support answer for everything is?
I see no reason why something that is useful to me in my everyday work should be removed just because some idiots call tech support before checking CAPS LOCK when typing passwords.
You realize, of course, that if CAPS LOCK goes, they'll replace it with ANOTHER WINDOWS KEY. My boss at work has a keyboard designed by a demon- there are FOUR WINDOWS KEYS on it. There are the two in the "standard" places, and two more under Insert and Page Down. It's a damn minefield of Windows keys, each one waiting to steal input focus from the current application. Every time I use his keyboard I hit one by mistake. (He hates it too, but hasn't bothered to get a new one since his typing skills have adapted to the hostile keyboard environment.)
Productivity in the US may increase by 10% if we got rid of the stupid thing. If you *need* to type in all caps, pick a menu-option in your word processor or other application.
I doubt your productivity estimate, and I use CAPS LOCK in many different applications. I see no reason why I should have to go around figuring out how to set up macros and key bindings in every application I use just so an AOL call center in Bangalore can lower its call volume.
I might add that I used CAPS LOCK six times so far just while typing this post, and if I didn't have one my finger would be aching by now.
I suspect in the majority of systems, the main-line (without exceptions) is tested/debugged pretty well, while the exception-lines with about ten times the complexity get about one tenth the attention.
That's why checked exceptions don't work in practice. They're great in theory but they run afoul of human nature. People want to get the main line working, and the compiler keeps giving them trouble about the exceptions. So they write catch blocks that swallow them so they can compile, and then they forget about them.
Someone at work wrote a cancellation mechanism that relied on Thread.interrupt(). This is another bad idea in Java, and it was even meant to be used to support cancellation mechanisms. In this case you'd click a Cancel or Stop button, and it would call interrupt() on the thread, setting its interrupt flag. The thread would periodically check its flag with isInterrupted() and finish up immediately if it was set.
That worked great until the thread found its way into code that routinely swallowed InterruptedExceptions. By design in Java, all blocking calls like wait() or sleep() are declared as throwing them, because someone might call interrupt() on a thread while it's blocked. And people immediately swallow them because they're usually an annoyance at the level you're working at when you're using wait() or sleep(). But since the designers of Java figured the exception handling code would be handling things, the interrupt flag isn't set in the case of an InterruptedException. So the Cancel and Stop buttons stopped working, because whenever you clicked on one, you were likely to catch the thread blocked on some low-level sleep() and its catch block would swallow the exception. (The culprit turned out to be the progress bar, which had a 2 millisecond sleep() somewhere in its paint routine.) To fix it, someone had to go around to all those empty catch blocks (all 10,000 of them) and have the current thread re-interrupt itself in each one.
Well that depends on what the exception handler did with the exception doesn't it? I doubt it got the graceful recovery that was waiting inside the if block. I think in this case it did a printStackTrace() and continued on its merry little way, leaving the user puzzled about what was going on.
It's not commonly known that many of the American founding fathers were libertarian computer consultants chafing at high tax brackets from England. In fact, Alexander Hamilton himself often spent weekends dispensing toy plastic muskets to inner city ragamuffins. And the foundations of libertarian thought are written right into the preamble to the Constitution:
"We the People of the United States, in Order to form a more perfect Union, establish Justice, insure domestic Tranquility, provide for the common defence, promote the general Welfare, and secure the Blessings of Liberty to ourselves and our Posterity, do ordain and establish this Constitution for the United States of America."
If that doesn't say "every man for himself" I don't know what does.
It was probably a bad example to use here, since it's not a computer newbie mistake, it's just a new-to-Java mistake. The guy who wrote it had a PhD from Stanford in math which is what made it funny when I came across it a few days ago.
The new operator is guaranteed to never evaluate to null in Java. If a TCP connection can't be made, the Socket constructor will throw an exception and you won't get to the next line at all. This is different from C++ where new evaluates to NULL to indicate failure.
The PHP and JSP are Turing complete. The resulting HTML is not- it's output.
:= a_total + c_total; := apples * a_price; := carrots + c_price;
Still, whether or not HTML is Turing complete is irrelevant. If you look at the mistakes that most beginning programmers make, it's that they have no understanding of the human-machine interface. They don't know how to communicate their intentions into forms that computers can understand.
People are used to conversing with people, not computers. Telling people what to do is much different than telling a computer what to do.
First of all computers have no common sense, and a human being has a variable amount of common sense that can be depended upon. So beginners write code like this, relying on the computer's common sense to fix it for them:
begin
readln("Number of Apples", apples);
readln("Number of Carrots", carrots);
readln("Price for 1 Apple", a_price);
readln("Price for 1 Carrot", c_price);
writeln("Total for Apples", a_total);
writeln("Total for Carrots", c_total);
writeln("Total", total);
total
a_total
c_total
end;
"It's logical what the right solution is, and the computer should reorder the instructions the right way."
Computers are infallible in certain ways that humans aren't, and this confuses people too. You see stuff like this from beginning programmers:
let x=0;
let x=0;
Why is it repeated? "In case it didn't get it right the first time". I actually found this in someone's old Java code:
Socket s = new Socket(ADDR, PORT);
if (s==null) {
//show error message...
}
Turing completeness really isn't what's important. The more fundamental skill is learning how to think when giving instructions to a machine, and for that, HTML is fine for a beginner. HTML will at least teach you that the browser won't read your mind, will encourage you to learn to fix problems by experimenting, and puts you in the correct frame of mind to realize that you will get exactly what you specify and nothing more.
And even if it turns out to be a passing interest, HTML is an extremely useful computer skill to have. And an understanding of HTML is pivotal to many real-world tasks in real programming languages, since HTML is such a common type of data to be parsed and generated by computer programs. I'd say if a terrified adult doesn't know HTML, that should be the first thing they should study.