Because the best way to argue against them is with insults and the lack of an actual argument. Seriously, if you're going to start the debate, at least provide something tangible.
Okay, here's something tangible. To the best of my understanding, a key difference between child porn and pirated content is that (for the most part) the producers of child porn do not want their content to be found via Google. They want the location to be findable only by becoming part of their circle of trust or whatever. As a result, when Google blocks child porn from search results, the producers are happy about it and take no action to get back into Google's search results.
By contrast, people who post pirated content do want their content to be easily searchable so that the general public will find it and download it. When Google blocks one warez site, the site moves to a different location so that it can be found again. This results in a constant cat-and-mouse game between the posters and the search giant. Heck, there's even a constant cat-and-mouse game going on between Google's YouTube division and pirated content posters, and that's on Google's own servers.
IIRC, in preschool, nap time was the part of the day when I used to dismantle and reassemble old, broken rotary dial phones, occasionally fixing them in the process.:-)
First problem there. Who thought of the bright idea to embed a programming language in a document format?
It works really well for generating certain types of web pages, such as forms, tables, etc.
While it doesn't really make much of a difference it would have been much more intuitive to have it the other way around.
You mean like PHP's heredoc syntax?
echo <<<EOT
<p>Blah blah blah</p>
EOT;
Also PHP have pretty much the same problem as VB. It has a lot of neat built in functions that does what you want plus a little bit extra, so you have to add extra glue around to compensate for PHP doing too much rather than adding together smaller functions to get the desired result.
When PHP is doing too much, at least on UNIX/Linux, you can typically call the POSIX functions from your PHP code instead.
By removing the rest of that sentence, you completely changed the meaning of what I said. C is a walking disaster, but PHP's non-pointer-based string/array handling removes the sharp edges that make C a walking disaster.
Let me restate that. Syntactically, PHP is very, very close to C with dollar signs. The syntax of its class implementation is somewhat different from that of C++, but given that pure C has no notion of classes whatsoever, this cannot reasonably be called a difference between C and PHP except inasmuch as such a syntax exists at all.
Direct memory access is precisely why C code has metric f**ktons of serious security holes. Pointers don't exist in PHP for a reason. Pointer manipulation truly has no place in proper code unless you're down in the kernel. For all other code, if you depend on such hackery, you're almost always doing it wrong.
PHP's conversion of data types is usually what a reasonable person would expect. C's excess rigor causes lots of headaches for little gain, and much of the gain you do get comes from avoiding security holes that would not exist were it not for the aforementioned stray pointers....
IMO, PHP arrays behave pretty sanely compared with the unholiness that is C's array syntax (and if you've ever needed an associative array in C, you'll wish you had a nice tall bridge to jump from). That said, I'm pretty sure I mentioned that difference, so the only thing we disagree on is which style is more programmer friendly.
I haven't dealt with PHP objects enough to have a strong opinion on that.
Session functionality is not really part of the language itself in any meaningful sense; it's just an optional library, and you can always roll your own session system if it doesn't meet your needs. For that matter, conceptually, the notion of sessions is, by its very nature, so hopelessly broken that where possible, you should try to redesign your code in a way that does not rely on server-side statefulness.
I'm not sure what you're talking about with respect to cookies. AFAIK, libcurl works pretty much the same way under C as it does under PHP. Are you talking about some other, broken HTTP client API here? How is that a flaw in the language?
Magic quotes and automatic registration of global variables are both unsupported in PHP 5.4 and later. You're complaining about what is, to most people, ancient history.
I do agree that PHP's standard library is probably too big, and that parts of it are a bit screwy. Then again, I'll see your PHP standard libraries and raise you the C++ STL.:-D
A significant percentage of those are leaky abstractions from the underlying C library routines, thus furthering my assertion that PHP is basically C with dollar signs.
And so on. Besides, if you haven't ripped out all your escaping code and replaced it with parameterized queries by now, chances are you've been compromised more than once already.
PHP is actually a pretty nice language. It's basically just C with dollar signs, classes, and better string and array handling, stuffed into a fairly straightforward HTML template language.
You hear so many horror stories about PHP because of what I would describe as a "meta problem". Like most languages that are primarily used for web coding, a sizable percentage of people who write code using PHP have no idea what they are doing, as their level of programming skill is only slightly above "can write out basic HTML markup using string manipulation". This results in terrible code with lots of horrifying bugs, poor performance, security holes, and so on. JavaScript, Ruby, etc. are also known to exhibit this phenomenon.
I'd be surprised if every computer involved in these sorts of transactions had an actual physical atomic clock built in. Instead, I would expect a single master clock that multiple devices synchronize themselves with, which opens up the possibility for local network propagation delays that can introduce slight imprecision. I could be wrong.
The obvious question, of course, is why such a route exists in the first place. If it's a road, people are allowed to drive on it. If people aren't allowed to drive on it, they should take reasonable steps to prevent people from... you know... driving on it.
I was the only person in my kindergarten class who couldn't sleep during the day. (I still can't sleep during the day unless I'm severely jet lagged.) I just sort of sat there and thought about stuff for that half hour or however long it was. I'm pretty sure my learning was not in any way compromised by this.
That conclusion is actually supported by the article, which says that kids who are used to taking naps don't learn as well if they don't take naps, but that kids who never take naps don't improve after taking one. So if all parties aren't willing, chances are, your kid is beyond the age where a nap is useful, pedagogically speaking.
In other words, it is important to make naps available to kids who need them, but it is not useful to force naps on kids whose brains matured earlier. In an ideal world, there should be something for those kids to do other than lying there and feeling bored—perhaps a trip to the school library to read something, at least for those kids whose reading skills are far enough along to do so. My guess is that there's probably a roughly 1:1 correlation between those two groups.
Trying to prevent distracted driving is simply an infeasible task. The reality of the world is that drivers are becoming increasingly distracted with every passing year, from GPS navigation devices to touchscreen radios, from Amber alerts on digital traffic signs to digital advertising billboards. All the other pieces of additional visual information that we didn't encounter twenty years ago make driving less safe, but reversing that trend is a bit like draining the Atlantic Ocean with a soup spoon. Not only will you never get there, but you'll also never really make any appreciable progress even though at first glance, you might think you are. Instead, we have to design vehicles, traffic lights, and other systems to be resilient to distraction and to minimize the negative ramifications thereof.
The reason for such an approach is that the problem you describe is not even remotely limited to texting; it also occurs for adjusting the radio, changing the air conditioning, scratching your back, or doing any of a million other possible things while stopped at the light. These things are only a problem because the traffic lights in America are substandard.
The best way to explain is with a quick anecdote. While walking around in Europe last week, by my estimation, about 80% of drivers were either on the phone or texting at lights, yet when the light turned green, they moved. Why? Because European traffic lights indicate not only when the light is about to turn red, but also when it is about to turn green. As a result, they don't have to constantly watch the light, waiting patiently for it to suddenly switch from red to green, but instead can glance up periodically and notice that it has moved to a red + yellow state (or red + orange in Europe), stop what they are doing, and be ready to begin driving again when the light turns green a few seconds later.
A Luddite, in modern English parlance, means a person who is opposed to technological change. What did you think it meant? The only mistake I made was leaving off the capital "L", though arguably it probably should go away in that usage.
No, you really don't. You deserve a parking ticket, and you deserve blame for the traffic snarls and loss of income, but any actual accidents are the fault of the people who made the driving mistakes that caused them.
It is only different because we have a bunch of luddites writing our traffic laws who don't understand technology, and thus create laws in which things that are legal to do on one device are illegal to do on another device solely because that other device is capable of making phone calls.
In the United States, unless it is on a city street, it is not generally legal to stop on the side of the road except for emergency purposes, though usually they won't hassle you about it. Still, technically it is legal for you to answer a phone call while driving, but not legal for you to pull over to the side of a freeway to answer it. Have I mentioned previously that all of our technology-related traffic laws are designed to make us less safe, not more safe? Because they really are—revenue über alles and all that.
Lesson learned: you're harder to catch if you're a moving target, save the texts for the highway, and drive home to sleep in your own bed.
Exactly. The worst problem with excessively strict enforcement occurs when people place a phone call, which texting laws invariably allow you to do, but which is almost indistinguishable from texting and can cause you to get pulled over and might even force you to fight the ticket in court. Before the texting laws went into effect, people held up their phones to dial so that they wouldn't have to look very far away from the road. Now, they keep them in their laps and look away from the road completely, all because they've heard stories from their friends about police being excessively aggressive at ticketing people using their phones for things other than making calls, which those laws were never intended to prevent, but end up preventing because the laws were worded by knee-jerk reactionary idiots who have no concept of how to write a properly scoped law, but I digress. For example, I had a friend get a ticket for changing the song that was playing on her iPhone. This is provably no less safe than changing the radio, and is entirely legal if the device is an iPod, but becomes illegal if the device also happens to be able to make phone calls because it isn't explicitly enumerated in the list of things you can do with a cellular phone while driving. The police officer agreed that the law was idiotic, but still gave her a ticket. Bad, bad, bad officer.
So yes, these are precisely the sorts of laws where aggressive enforcement is unquestionably detrimental to public safety. Police officers have not just a right, but a responsibility to choose whether or not a ticket is warranted under the circumstances. If the letter of the law contradicts its intended spirit, as is clearly the case for every texting/cell phone driving law I've seen so far, the police have the right and the responsibility to selectively enforce that law when it makes sense to do so. Enforcing laws more strictly than necessary makes our roads less safe, resulting in additional traffic deaths. For this reason, IMO, the officer described in this story should be terminated immediately for abuse of power under color of authority.
Also, IMO, everyone involved in writing these laws should be charged with negligent homicide for every death arising out of accidents that were caused by someone trying to avoid getting hassled by the police for doing something that is safe and allowed by law but that is problematic because of these laws. Maybe then, future lawmakers would learn to think before they vote. Hey, I can dream, can't I?
No, the stopped driver deserves zero blame. It is a driver's responsibility to not hit stationary objects, without regard to why that object is stationary or what that object is. If a driver cannot handle that responsibility, he/she should not be driving. It's one thing to hit a vehicle that pulls out in front of you at a slow pace. It's quite another to hit a parked car. Unless there were weather reasons, that's simply inexcusable.
Yes, and if the driver in front of you fails to move, it results in, at worst, a 5 MPH nudge and a little bit of scuffed paint on your bumper. You cannot get killed or kill someone by remaining stationary at a light unless someone on the road is driving way too fast and is not paying the slightest bit of attention to the road in front of him/her. Period. When that happens, it's criminally negligent homicide.
Yeah, but the semantic roles are mostly limited to things like buttons and other UI elements, which isn't really relevant for most books. Also, the entire notion of using attributes for semantic meaning instead of tag names is at best a hack to make things kind of work.
HTML does have some semantic tags, mind you. The problem is not that you can't do semantic tagging, but rather that you can do non-semantic tagging. Most non-HTML output languages are inherently more structured than HTML is in its most minimally structured forms. Converting DocBook to LaTeX is easy because DocBook is always strictly structured (with a handful of awkward exceptions in the general vicinity of the bibliography, IIRC). Converting arbitrary HTML into LaTeX is a recipe for jumping out a tenth-story window.
Thus, you can certainly use HTML5 as a source format, but it is far easier to stray from the one true path of rigorous semantic tagging with HTML5, and every time you do, you're creating content that will cause headaches for you later. Better to start with a more strictly structured markup language and relax the rules only when needed, rather than start with something inherently almost completely unstructured and try to enforce structural rules yourself.:-)
HTML5 is actually an excellent source format for producing paginated content...
Which is actually completely untrue. HTML5 is a terrible source format because it is predominantly a visual markup, not a semantic one. You can sort of graft semantics onto it through CSS classes, but any such solution is inherently fragile and at the very least a publisher-specific standard, and likely a book-specific standard.
DocBook is an excellent source format. Its tags are semantic by their nature, which makes it much better as a source format, because it can not only be trivially converted to HTML5 for electronic publication, but also to LaTeX for print publication. It will also be easy to convert from that to whatever format replaces HTML5 ten years from now. And of course you can always add additional semantic tags to extend it if you need some book-specific or publisher-specific functionality.
Slashdot Mirror
Okay, here's something tangible. To the best of my understanding, a key difference between child porn and pirated content is that (for the most part) the producers of child porn do not want their content to be found via Google. They want the location to be findable only by becoming part of their circle of trust or whatever. As a result, when Google blocks child porn from search results, the producers are happy about it and take no action to get back into Google's search results.
By contrast, people who post pirated content do want their content to be easily searchable so that the general public will find it and download it. When Google blocks one warez site, the site moves to a different location so that it can be found again. This results in a constant cat-and-mouse game between the posters and the search giant. Heck, there's even a constant cat-and-mouse game going on between Google's YouTube division and pirated content posters, and that's on Google's own servers.
IIRC, in preschool, nap time was the part of the day when I used to dismantle and reassemble old, broken rotary dial phones, occasionally fixing them in the process. :-)
It works really well for generating certain types of web pages, such as forms, tables, etc.
You mean like PHP's heredoc syntax?
echo <<<EOT
<p>Blah blah blah</p>
EOT;
When PHP is doing too much, at least on UNIX/Linux, you can typically call the POSIX functions from your PHP code instead.
By removing the rest of that sentence, you completely changed the meaning of what I said. C is a walking disaster, but PHP's non-pointer-based string/array handling removes the sharp edges that make C a walking disaster.
Let me restate that. Syntactically, PHP is very, very close to C with dollar signs. The syntax of its class implementation is somewhat different from that of C++, but given that pure C has no notion of classes whatsoever, this cannot reasonably be called a difference between C and PHP except inasmuch as such a syntax exists at all.
IMO, PHP arrays behave pretty sanely compared with the unholiness that is C's array syntax (and if you've ever needed an associative array in C, you'll wish you had a nice tall bridge to jump from). That said, I'm pretty sure I mentioned that difference, so the only thing we disagree on is which style is more programmer friendly.
I do agree that PHP's standard library is probably too big, and that parts of it are a bit screwy. Then again, I'll see your PHP standard libraries and raise you the C++ STL. :-D
A significant percentage of those are leaky abstractions from the underlying C library routines, thus furthering my assertion that PHP is basically C with dollar signs.
And so on. Besides, if you haven't ripped out all your escaping code and replaced it with parameterized queries by now, chances are you've been compromised more than once already.
PHP is actually a pretty nice language. It's basically just C with dollar signs, classes, and better string and array handling, stuffed into a fairly straightforward HTML template language.
You hear so many horror stories about PHP because of what I would describe as a "meta problem". Like most languages that are primarily used for web coding, a sizable percentage of people who write code using PHP have no idea what they are doing, as their level of programming skill is only slightly above "can write out basic HTML markup using string manipulation". This results in terrible code with lots of horrifying bugs, poor performance, security holes, and so on. JavaScript, Ruby, etc. are also known to exhibit this phenomenon.
When did we start talking about airport security?
I'd be surprised if every computer involved in these sorts of transactions had an actual physical atomic clock built in. Instead, I would expect a single master clock that multiple devices synchronize themselves with, which opens up the possibility for local network propagation delays that can introduce slight imprecision. I could be wrong.
Or, more likely, 5. The clocks weren't quite synchronized and the trade actually occurred several milliseconds later.
The obvious question, of course, is why such a route exists in the first place. If it's a road, people are allowed to drive on it. If people aren't allowed to drive on it, they should take reasonable steps to prevent people from... you know... driving on it.
You joke, but an audible signal would not be particularly difficult to implement, and would be a really useful addition.
I was the only person in my kindergarten class who couldn't sleep during the day. (I still can't sleep during the day unless I'm severely jet lagged.) I just sort of sat there and thought about stuff for that half hour or however long it was. I'm pretty sure my learning was not in any way compromised by this.
That conclusion is actually supported by the article, which says that kids who are used to taking naps don't learn as well if they don't take naps, but that kids who never take naps don't improve after taking one. So if all parties aren't willing, chances are, your kid is beyond the age where a nap is useful, pedagogically speaking.
In other words, it is important to make naps available to kids who need them, but it is not useful to force naps on kids whose brains matured earlier. In an ideal world, there should be something for those kids to do other than lying there and feeling bored—perhaps a trip to the school library to read something, at least for those kids whose reading skills are far enough along to do so. My guess is that there's probably a roughly 1:1 correlation between those two groups.
Trying to prevent distracted driving is simply an infeasible task. The reality of the world is that drivers are becoming increasingly distracted with every passing year, from GPS navigation devices to touchscreen radios, from Amber alerts on digital traffic signs to digital advertising billboards. All the other pieces of additional visual information that we didn't encounter twenty years ago make driving less safe, but reversing that trend is a bit like draining the Atlantic Ocean with a soup spoon. Not only will you never get there, but you'll also never really make any appreciable progress even though at first glance, you might think you are. Instead, we have to design vehicles, traffic lights, and other systems to be resilient to distraction and to minimize the negative ramifications thereof.
The reason for such an approach is that the problem you describe is not even remotely limited to texting; it also occurs for adjusting the radio, changing the air conditioning, scratching your back, or doing any of a million other possible things while stopped at the light. These things are only a problem because the traffic lights in America are substandard.
The best way to explain is with a quick anecdote. While walking around in Europe last week, by my estimation, about 80% of drivers were either on the phone or texting at lights, yet when the light turned green, they moved. Why? Because European traffic lights indicate not only when the light is about to turn red, but also when it is about to turn green. As a result, they don't have to constantly watch the light, waiting patiently for it to suddenly switch from red to green, but instead can glance up periodically and notice that it has moved to a red + yellow state (or red + orange in Europe), stop what they are doing, and be ready to begin driving again when the light turns green a few seconds later.
A Luddite, in modern English parlance, means a person who is opposed to technological change. What did you think it meant? The only mistake I made was leaving off the capital "L", though arguably it probably should go away in that usage.
No, you really don't. You deserve a parking ticket, and you deserve blame for the traffic snarls and loss of income, but any actual accidents are the fault of the people who made the driving mistakes that caused them.
It is only different because we have a bunch of luddites writing our traffic laws who don't understand technology, and thus create laws in which things that are legal to do on one device are illegal to do on another device solely because that other device is capable of making phone calls.
In the United States, unless it is on a city street, it is not generally legal to stop on the side of the road except for emergency purposes, though usually they won't hassle you about it. Still, technically it is legal for you to answer a phone call while driving, but not legal for you to pull over to the side of a freeway to answer it. Have I mentioned previously that all of our technology-related traffic laws are designed to make us less safe, not more safe? Because they really are—revenue über alles and all that.
Exactly. The worst problem with excessively strict enforcement occurs when people place a phone call, which texting laws invariably allow you to do, but which is almost indistinguishable from texting and can cause you to get pulled over and might even force you to fight the ticket in court. Before the texting laws went into effect, people held up their phones to dial so that they wouldn't have to look very far away from the road. Now, they keep them in their laps and look away from the road completely, all because they've heard stories from their friends about police being excessively aggressive at ticketing people using their phones for things other than making calls, which those laws were never intended to prevent, but end up preventing because the laws were worded by knee-jerk reactionary idiots who have no concept of how to write a properly scoped law, but I digress. For example, I had a friend get a ticket for changing the song that was playing on her iPhone. This is provably no less safe than changing the radio, and is entirely legal if the device is an iPod, but becomes illegal if the device also happens to be able to make phone calls because it isn't explicitly enumerated in the list of things you can do with a cellular phone while driving. The police officer agreed that the law was idiotic, but still gave her a ticket. Bad, bad, bad officer.
So yes, these are precisely the sorts of laws where aggressive enforcement is unquestionably detrimental to public safety. Police officers have not just a right, but a responsibility to choose whether or not a ticket is warranted under the circumstances. If the letter of the law contradicts its intended spirit, as is clearly the case for every texting/cell phone driving law I've seen so far, the police have the right and the responsibility to selectively enforce that law when it makes sense to do so. Enforcing laws more strictly than necessary makes our roads less safe, resulting in additional traffic deaths. For this reason, IMO, the officer described in this story should be terminated immediately for abuse of power under color of authority.
Also, IMO, everyone involved in writing these laws should be charged with negligent homicide for every death arising out of accidents that were caused by someone trying to avoid getting hassled by the police for doing something that is safe and allowed by law but that is problematic because of these laws. Maybe then, future lawmakers would learn to think before they vote. Hey, I can dream, can't I?
No, the stopped driver deserves zero blame. It is a driver's responsibility to not hit stationary objects, without regard to why that object is stationary or what that object is. If a driver cannot handle that responsibility, he/she should not be driving. It's one thing to hit a vehicle that pulls out in front of you at a slow pace. It's quite another to hit a parked car. Unless there were weather reasons, that's simply inexcusable.
Yes, and if the driver in front of you fails to move, it results in, at worst, a 5 MPH nudge and a little bit of scuffed paint on your bumper. You cannot get killed or kill someone by remaining stationary at a light unless someone on the road is driving way too fast and is not paying the slightest bit of attention to the road in front of him/her. Period. When that happens, it's criminally negligent homicide.
Yeah, but the semantic roles are mostly limited to things like buttons and other UI elements, which isn't really relevant for most books. Also, the entire notion of using attributes for semantic meaning instead of tag names is at best a hack to make things kind of work.
HTML does have some semantic tags, mind you. The problem is not that you can't do semantic tagging, but rather that you can do non-semantic tagging. Most non-HTML output languages are inherently more structured than HTML is in its most minimally structured forms. Converting DocBook to LaTeX is easy because DocBook is always strictly structured (with a handful of awkward exceptions in the general vicinity of the bibliography, IIRC). Converting arbitrary HTML into LaTeX is a recipe for jumping out a tenth-story window.
Thus, you can certainly use HTML5 as a source format, but it is far easier to stray from the one true path of rigorous semantic tagging with HTML5, and every time you do, you're creating content that will cause headaches for you later. Better to start with a more strictly structured markup language and relax the rules only when needed, rather than start with something inherently almost completely unstructured and try to enforce structural rules yourself. :-)
Which is actually completely untrue. HTML5 is a terrible source format because it is predominantly a visual markup, not a semantic one. You can sort of graft semantics onto it through CSS classes, but any such solution is inherently fragile and at the very least a publisher-specific standard, and likely a book-specific standard.
DocBook is an excellent source format. Its tags are semantic by their nature, which makes it much better as a source format, because it can not only be trivially converted to HTML5 for electronic publication, but also to LaTeX for print publication. It will also be easy to convert from that to whatever format replaces HTML5 ten years from now. And of course you can always add additional semantic tags to extend it if you need some book-specific or publisher-specific functionality.
We are not at war against Isreal.
Unethical, yes. Unconstitutional, probably. Heinous, certainly. Treason, no.
You say it wasn't alien life, but that's just what Anubis wanted you to believe.