As I understand it, the out-of-spec contamination level is measured inside the plant, not at the standard distance for test wells. The test wells are still within spec. They'll get there eventually, in all likelihood, but they're not there yet.
There's a big difference between a pinhole leak in a coolant pipe and a fundamentally flawed reactor design with no containment vessel and unsafe control rod designs operating way outside its safety margins. There's a difference between not knowing where every single coolant pipe is located and and deliberately ignoring safety alarms. I don't think there's much chance that this could cause a Chernobyl-level event in the near term.
Should the reactor be shut down? Probably, if only because A. there's probably no way to fix an underground pipe leak without doing so, and B. if one pipe is leaking (and there have been *several* leaks at this plant lately), they're all probably on the verge of leaking, which means these problems are only going to get worse until they actually do pose a real risk.
Or you could just make the checksum be a hash of the last dozen or so packets of communication history so that the attacker can no longer practically know the complete plaintext. Alternatively, you could add a randomly-generated piece of data into each packet that provides an additional value to add in during the hashing of the following packet.
No, but we're nowhere near the end of abuse of kiddie porn as a justification for invasion of privacy. I'm just waiting to see someone propose a law that requires children be photographed naked annually with the pictures stored in a national database so that they can more rapidly identify the victims of abuse. From a logical perspective, it's completely valid. From an ethical perspective, it's completely appalling.
First, that would be a really difficult timing attack to pull off, as you would have to be able to reliably identify the point at which you were no longer authenticating with the remote server. Second, because ssh sends data in discrete packets that may include one or several characters, the code would have to guess how many characters were in each packet; this should make it fairly unlikely that you would be successful. Third, even if it were possible, it is trivially avoidable by including a checksum in each block of text and encrypting it with the OTP just like you do with the actual stream data. If the checksum doesn't match after decoding, the packet is discarded and the sender has to resend it. Presto, no more injection attacks.
Really, I think it's more a case of balancing the risk of the Windows box getting 0wn3d while the connection to the remote machine is active and somebody taking advantage of that to muck around on your server while you're gone versus the risk of the Windows box getting 0wn3d and somebody capturing the password when you log in and using it to impersonate you later. The former requires a much more sophisticated cracker than the latter, so I'd probably say staying logged in is safer as long as you have pretty airtight physical security.
Interesting? Really? I was going for "Funny". If you actually use it, you'll discover that it's pretty darn impractical in a production environment. More of a demonstration of several advanced scripting techniques (simulating associative arrays, for example) than anything practical. Still a fun little piece of code.
Penicillin? Not a mistake so much as general messiness. The guy stacked up some bacterial cultures and went on vacation. One of them grew mold. He noticed that the bacteria near the mold were dead.
Especially when the rest of the language does go all the way ("01" + 2 = 3).
The rest of the language is wrong. Being wrong in that way for array indices would be disastrous.:-) (Okay, so you could work around it by prefixing every array index with an underscore or something, but really, why?)
But seriously, there's not a real discrepancy there. The operation "+" only operates on numbers, therefore the operands are implicitly coerced into numbers if possible. Things that can't be coerced are treated as zero. The only alternative would be to treat a string value as a reason to crash, and I'm not sure that would be a benefit; it would just result in people littering the code with unnecessary (int) casts.. That's the nice thing about PHP using a separate operator for string concatenation---there's no ambiguity like there is in JavaScript....
The reason why foo['2'] and foo[2] refer to the same element is because 2 gets promoted to string, not because '2' gets demoted to integer (it does get demoted temporarily when assigning to the element, but only for the purpose of updating length).
Didn't I say that? *shrugs*
Either way, I'm not sure I see the problem. If you could create an array with explicit indices of both '2' and 2 in it, you're just asking for the next programmer who has to maintain your code to jump through the internet and pummel you with a clue-by-four.:-)
That said, I do agree that having separate numeric-indexed and associative arrays would be a big win, just for different reasons. From a performance perspective, maintaining a numeric array is a lot easier than maintaining an associative array. I'm sure there are plenty of optimizations that would be possible if numeric arrays never had to be promotable to associative arrays....
It's a valid use case, but as you describe it, it means that every time you actually want to check the return value of fopen(), you use @ anyway. So whenever you use fopen() without @, you're effectively asserting that the file exists, and the following code will not have any checks (otherwise you'd use @ to avoid the warning message). If so, why isn't the use of fopen() without @ not a critical error that will prevent the following code from running, terminating the application - for example, by throwing an exception (as it happens in e.g. Java, C#, Python...)?
No, no, no. I check the return value every time, whether I use "@" or not. The return value check is for displaying a sensible message to the end user. In deployment, the PHP-generated message is *always* suppressed, "@" or no "@", so the return value check must always be there for every call.
I use "@" to suppress the PHP-generated debug message during development for specific calls where the failure is expected/harmless so that my HTML layout isn't hopelessly broken by those bogus warnings. They're suppressed because of the high false positive rate on that particular call. I omit the "@" on most calls because they should not fail even during development. That way, I get the detailed debug info during testing.
Either way, in the deployment phase, the "@" effectively occurs for every call, and the only error output comes as a result of checking the return value and generating a user-centric message.
If so, why isn't the use of fopen() without @ not a critical error that will prevent the following code from running, terminating the application - for example, by throwing an exception (as it happens in e.g. Java, C#, Python...)?
Because in deployment, that's the last thing you'd want. You want to trap the bad return value and display a user-friendly "Your changes could not be saved" formatted to match the site rather than "Java.lang exception blah blah blah" in black text on white or whatever.
Also, I generally need to identify that something went wrong as close as possible to the call because that's the only part of the code that knows precisely what was happening at the time, and thus that's the only place where a precise error message can be generated. It is also often necessary to roll back earlier operations when one part of a complex operation fails. That's not possible except right at that point in the code. If I can't just let the exception bubble up very far in my call stack, then there is no real advantage to using an exception over a return value.
Finally, I usually don't care why a call failed outside of the debug environment. I only care that it failed. With return values, I can typically handle every possible failed exit status with a single if statement. With exceptions, depending on how the particular function was designed, it can require multiply-nested try/catch blocks, one for each class of exceptions, all of which then have to set some flag so that later in the function you can treat each of them as being the same fundamental failure (or add an unnecessary function call whose sole purpose is to call the exception-throwing function, catch the exception, and return an exit status).
Also, exceptions are, in my opinion, simply a bad programming practice that leads to sloppy, buggy, insecure programming.
57 seconds. And I would have been within a couple of seconds a decade ago, too. Most musicians tend to have a fairly good concept of tempo. There was a stretch in the 30s and 40s where I felt like I was rushing, and apparently I was. Didn't quite compensate enough in the 50s.
I figure the younger people were just grumbling and thinking, "I gotta get this over with so I can do something more interesting." By contrast, the older folks were probably bored, and got distracted. I wonder how many of the older people counted for longer because they counted a decade twice.
Or, to be a smart aleck, for some of the oldest folks, "Uh... what was after 14? Oh, yeah. 14. Uh.. what was after 14?":-D
Javascript doesn't allow you to access Objects (aka Associative Arrays) via numeric indexes, if you have found a way to do this you are doing in wrong..
It does, but only for the numeric keys. I was remembering wrong about doing it for non-numeric keys. My bad.:-)
It's an error that you should be checking for. It's also a warning message that provides useful details when debugging but provides filesystem layout info that should not be exposed when deploying. By gating the decision off the server configuration, you have an extra measure of security, albeit mostly through obscurity.
Case in point, when I'm processing an image file, I also look to see if there's a file in the same folder called foo.jpg.rot and if so, I parse it for rotation information. If that open fails, I use the default values. I certainly could avoid it by wrapping the whole block in an explicit "if (file_exists){" block, but that adds an extra nesting level, and I still need to check to see if the open succeeded just in case there's a permission problem on the server. Adding the "@" means that I can just let the fopen call fail, skip reading from it, and move on even when debugging, confident that the warning messages from PHP on that particular call are more likely to be bogus than real.
Because it is only disabled on a one-off basis, though, I still get the advantage of PHP spewing a warning message that contains the full path to the file for other failed calls to fopen. So when the subsequent write of that file (with filled-in default data) fails because the enclosing directory doesn't exist due to some path translation error, I know about it, and I can quickly take action without having to add additional debug statements to obtain the full path info.
In deployment, those warning messages go away entirely, and if the subsequent open for writing fails, the function cleans up and returns a simplified error message that indicates that changes to the rotation could not be saved, but does not provide a complete filesystem path that the user doesn't care about (and really shouldn't know anyway).
That's just one example, but the pattern holds for pretty much anything in programming. There's a lot of debug info when certain calls fail that can be useful while debugging but that is not so useful in the deployment stage. Think of it as the equivalent of setting the logging level to LOG_DEBUG in syslogd.conf and it should make a lot more sense.
Most well-written PHP code (at least, code that proponents of the language tout as well-written) is also done using dot (er, arrow) notation and classes. This doesn't make it a subset of C++ in any way, since classes are neither invented by C++, nor exemplified by it.
My point was that you can write basic PHP without any understanding of OOP. The core bits are pretty much procedural. With Javascript, even trivial string manipulation or number rounding requires you to understand OOP and dot syntax. Compare JavaScript's Math.floor(3.4) with PHP's floor(3.4), JavaScript' mystring.substr(1,3) with PHP's substr($mystring, 1, 3), etc.
As for classes in PHP, IMHO, that really depends on how big the code is. If there are units of functionality that are easily reusable, self-contained, and tend towards data structures, then classes aren't a bad idea. For short programs, though, classes often just make the code larger, harder to read, and more CPU intensive. There's a time and a place, and I use them quite a bit, but I'm also careful not to overuse them, having seen just what painful joys that leads to.:-D
Are we talking about JS-in-a-browser here, or JS as a free-standing general-purpose language?
In a browser. I've never seen anyone use JavaScript as a general-purpose language.... I guess you could, but it just seems like an odd choice of language with limited ability to interface to anything else.
You misunderstand. The issue isn't that "08" is not treated as integer, the issue is that "8" is. Strings aren't integers, why make an implicit conversion there, especially when it's so inconsistent?
My point about the "8" versus 8 was that there's really not much need to make a distinction between integers and strings containing exactly an integer and nothing else. You're either using an array with numeric keys and iterators or you're using it associatively. Trying to mix the two is guaranteed to be a mess in any language. Even if the language keeps them distinct, you're creating confusion.
JavaScript is more consistent there in that it doesn't even have numeric keys - they're strings only. So it just converts any other type to string, and calls it done.
Actually, it sort of does. JavaScript behaves a lot like PHP. If you use numeric indices, it maintains a variable called count that is one higher than the largest numerical index used. Non-numeric indices don't modify this value. However, strings that contain nothing but a number do change this value. For example:
foo = new Array();
foo['2'] = "x";
alert(foo[2]);
alert(foo.length);
Notice that not only is the value of 1 promoted to a string for dereferencing purposes, but also the string value '1' is demoted to an integer and affects the length as though you had assigned into the array with numeric keys. This change of foo.count does not occur if you use a non-numeric key (e.g. 'x' instead of '2').
Whether you promote from numbers to strings (JS) or strings to numbers (PHP) is largely an irrelevant implementation detail as long as there is exactly one string that maps onto any given numeric value (which seems to be true, at least in PHP).
Now in the more general case, arguing that for comparison purposes and similar, numbers and strings shouldn't be treated the same way... well, I tend to agree with you, but I'm afraid that ship has pretty much sailed, and it's not a very big ship, so I won't lose sleep over it....:-) The existence of === and !== in PHP, Perl, and the like is generally good enough for when those differences really matter.
I disagree. PHP actually does the right thing for a web-based service, IMHO. End-user errors are useful for end users during the deployment phase. The PHP debug output messages are useful info for developers during debugging because most of the failures are caused by a typo you made five minutes earlier. They're basically two sides of the same coin. Sure, you could print your own error message with more or less info depending on whether you're in debug mode or not, but that's a good bit of extra coding effort for no real gain over the way PHP works now.
Mainly because I have a fundamental difference of opinion when it comes to return values versus exceptions. The Java folks seem to prefer the latter quite frequently. I tend to think that exceptions are for things that are truly exceptional---the equivalent to a kernel panic---something that should almost always cause the program to crash or at most, clean up and die. Thus, exceptions should never be thrown by any standard library because no library can reasonably determine what is or is not fatal to the application that calls it.
And even within application code itself, exceptions are really just a crutch so that programmers can be lazy and skip error checking throughout large blocks of their code. The result, at least in my experience, tends to be pretty much what you would expect---buggy code that crashes or misbehaves with regularity. That's not saying you can't write good code in Java, just that in my experience, that's the exception rather than the rule. No pun intended. Exceptions save a little bit of time during the coding phase, but they make it much harder to debug certain classes of problems. They're basically the Java equivalent of setjmp or GOTO---well, not quite that bad, but close.
I know, $10 answer to a fifty cent question, but....
The @ syntax is not a try/catch. PHP doesn't stop execution when it encounters errors opening files and stuff. It merely blasts a warning message to the output stream (web client). The @ operator suppresses that output. It's equivalent to sending the perror() after a failed fopen() call to/dev/null. Whether the command succeeds or fails, control still returns to your code after the statement. The @ operator merely suppresses the error message generated by PHP so that you can display a more appropriately formatted and/or more useful error message (or not display a message at all if the failure is expected). In a production environment, most people disable the warning output from PHP anyway, making it basically a no-op except during debugging.
If you folks want an argument against PHP, you're all going about it wrong. Probably the best argument against PHP is that it makes it easy to design yourself into a corner---putting code into the middle of HTML templates that suddenly needs to be able to set a header field and "whoops, that has already been sent", putting code into the middle of templates that needs to change the content up a level, and "whoops, have to add a hack over here to fix that", etc. The result is that for really simple sites, PHP is awesome, but it has real problems scaling to more complicated designs without dropping the templates (or at best, including them on the back end after you do a lot of compute processing up front to set things up, choose a template programmatically, etc.).
Or you could simply attack it for being a lot slower than C and leading to design patterns that waste lots of memory. For example, associative arrays are simple and easy to use, but 90% of the time, there are much simpler data structures that can do just as well. If your data structures are small, no problem. If you deal with something big, the difference in memory pressure between a clean, lightweight binary tree (even without balancing) and an associative array can result in an order of magnitude impact in performance (or two or three).
Slashdot Mirror
As I understand it, the out-of-spec contamination level is measured inside the plant, not at the standard distance for test wells. The test wells are still within spec. They'll get there eventually, in all likelihood, but they're not there yet.
Accelerometers? Stepper motors and/or rotary encoders are your friend.
There's a big difference between a pinhole leak in a coolant pipe and a fundamentally flawed reactor design with no containment vessel and unsafe control rod designs operating way outside its safety margins. There's a difference between not knowing where every single coolant pipe is located and and deliberately ignoring safety alarms. I don't think there's much chance that this could cause a Chernobyl-level event in the near term.
Should the reactor be shut down? Probably, if only because A. there's probably no way to fix an underground pipe leak without doing so, and B. if one pipe is leaking (and there have been *several* leaks at this plant lately), they're all probably on the verge of leaking, which means these problems are only going to get worse until they actually do pose a real risk.
Or you could just make the checksum be a hash of the last dozen or so packets of communication history so that the attacker can no longer practically know the complete plaintext. Alternatively, you could add a randomly-generated piece of data into each packet that provides an additional value to add in during the hashing of the following packet.
No, but we're nowhere near the end of abuse of kiddie porn as a justification for invasion of privacy. I'm just waiting to see someone propose a law that requires children be photographed naked annually with the pictures stored in a national database so that they can more rapidly identify the victims of abuse. From a logical perspective, it's completely valid. From an ethical perspective, it's completely appalling.
First, that would be a really difficult timing attack to pull off, as you would have to be able to reliably identify the point at which you were no longer authenticating with the remote server. Second, because ssh sends data in discrete packets that may include one or several characters, the code would have to guess how many characters were in each packet; this should make it fairly unlikely that you would be successful. Third, even if it were possible, it is trivially avoidable by including a checksum in each block of text and encrypting it with the OTP just like you do with the actual stream data. If the checksum doesn't match after decoding, the packet is discarded and the sender has to resend it. Presto, no more injection attacks.
Really, I think it's more a case of balancing the risk of the Windows box getting 0wn3d while the connection to the remote machine is active and somebody taking advantage of that to muck around on your server while you're gone versus the risk of the Windows box getting 0wn3d and somebody capturing the password when you log in and using it to impersonate you later. The former requires a much more sophisticated cracker than the latter, so I'd probably say staying logged in is safer as long as you have pretty airtight physical security.
Interesting? Really? I was going for "Funny". If you actually use it, you'll discover that it's pretty darn impractical in a production environment. More of a demonstration of several advanced scripting techniques (simulating associative arrays, for example) than anything practical. Still a fun little piece of code.
Penicillin? Not a mistake so much as general messiness. The guy stacked up some bacterial cultures and went on vacation. One of them grew mold. He noticed that the bacteria near the mold were dead.
No, I meant I was speeding up when I was counting 30 through 49.
Don't forget shell-script-based servers. It has a much smaller memory footprint than Apache, and it even runs PHP/Perl scripts. :-D
You use <a href="url"> to write <a href="url">, FWIW.
I have some ideas, and none of them inspire confidence. :-D
Neat. When I was dealing with that, PHP was still in 5.0, or maybe 5.1. Still, good to know.
PHP 5 is pretty neat. Too bad there weren't any prequels.
The rest of the language is wrong. Being wrong in that way for array indices would be disastrous. :-) (Okay, so you could work around it by prefixing every array index with an underscore or something, but really, why?)
But seriously, there's not a real discrepancy there. The operation "+" only operates on numbers, therefore the operands are implicitly coerced into numbers if possible. Things that can't be coerced are treated as zero. The only alternative would be to treat a string value as a reason to crash, and I'm not sure that would be a benefit; it would just result in people littering the code with unnecessary (int) casts.. That's the nice thing about PHP using a separate operator for string concatenation---there's no ambiguity like there is in JavaScript....
Didn't I say that? *shrugs*
Either way, I'm not sure I see the problem. If you could create an array with explicit indices of both '2' and 2 in it, you're just asking for the next programmer who has to maintain your code to jump through the internet and pummel you with a clue-by-four. :-)
That said, I do agree that having separate numeric-indexed and associative arrays would be a big win, just for different reasons. From a performance perspective, maintaining a numeric array is a lot easier than maintaining an associative array. I'm sure there are plenty of optimizations that would be possible if numeric arrays never had to be promotable to associative arrays....
No, no, no. I check the return value every time, whether I use "@" or not. The return value check is for displaying a sensible message to the end user. In deployment, the PHP-generated message is *always* suppressed, "@" or no "@", so the return value check must always be there for every call.
I use "@" to suppress the PHP-generated debug message during development for specific calls where the failure is expected/harmless so that my HTML layout isn't hopelessly broken by those bogus warnings. They're suppressed because of the high false positive rate on that particular call. I omit the "@" on most calls because they should not fail even during development. That way, I get the detailed debug info during testing.
Either way, in the deployment phase, the "@" effectively occurs for every call, and the only error output comes as a result of checking the return value and generating a user-centric message.
Because in deployment, that's the last thing you'd want. You want to trap the bad return value and display a user-friendly "Your changes could not be saved" formatted to match the site rather than "Java.lang exception blah blah blah" in black text on white or whatever.
Also, I generally need to identify that something went wrong as close as possible to the call because that's the only part of the code that knows precisely what was happening at the time, and thus that's the only place where a precise error message can be generated. It is also often necessary to roll back earlier operations when one part of a complex operation fails. That's not possible except right at that point in the code. If I can't just let the exception bubble up very far in my call stack, then there is no real advantage to using an exception over a return value.
Finally, I usually don't care why a call failed outside of the debug environment. I only care that it failed. With return values, I can typically handle every possible failed exit status with a single if statement. With exceptions, depending on how the particular function was designed, it can require multiply-nested try/catch blocks, one for each class of exceptions, all of which then have to set some flag so that later in the function you can treat each of them as being the same fundamental failure (or add an unnecessary function call whose sole purpose is to call the exception-throwing function, catch the exception, and return an exit status).
Also, exceptions are, in my opinion, simply a bad programming practice that leads to sloppy, buggy, insecure programming.
http://www.joelonsoftware.com/items/2003/10/13.html
http://silkandspinach.net/2005/06/14/exceptions-considered-harmful/
http://blogs.msdn.com/larryosterman/archive/2004/09/10/228068.aspx
57 seconds. And I would have been within a couple of seconds a decade ago, too. Most musicians tend to have a fairly good concept of tempo. There was a stretch in the 30s and 40s where I felt like I was rushing, and apparently I was. Didn't quite compensate enough in the 50s.
I figure the younger people were just grumbling and thinking, "I gotta get this over with so I can do something more interesting." By contrast, the older folks were probably bored, and got distracted. I wonder how many of the older people counted for longer because they counted a decade twice.
Or, to be a smart aleck, for some of the oldest folks, "Uh... what was after 14? Oh, yeah. 14. Uh.. what was after 14?" :-D
I keed! I keed!
It does, but only for the numeric keys. I was remembering wrong about doing it for non-numeric keys. My bad. :-)
It's an error that you should be checking for. It's also a warning message that provides useful details when debugging but provides filesystem layout info that should not be exposed when deploying. By gating the decision off the server configuration, you have an extra measure of security, albeit mostly through obscurity.
Case in point, when I'm processing an image file, I also look to see if there's a file in the same folder called foo.jpg.rot and if so, I parse it for rotation information. If that open fails, I use the default values. I certainly could avoid it by wrapping the whole block in an explicit "if (file_exists){" block, but that adds an extra nesting level, and I still need to check to see if the open succeeded just in case there's a permission problem on the server. Adding the "@" means that I can just let the fopen call fail, skip reading from it, and move on even when debugging, confident that the warning messages from PHP on that particular call are more likely to be bogus than real.
Because it is only disabled on a one-off basis, though, I still get the advantage of PHP spewing a warning message that contains the full path to the file for other failed calls to fopen. So when the subsequent write of that file (with filled-in default data) fails because the enclosing directory doesn't exist due to some path translation error, I know about it, and I can quickly take action without having to add additional debug statements to obtain the full path info.
In deployment, those warning messages go away entirely, and if the subsequent open for writing fails, the function cleans up and returns a simplified error message that indicates that changes to the rotation could not be saved, but does not provide a complete filesystem path that the user doesn't care about (and really shouldn't know anyway).
That's just one example, but the pattern holds for pretty much anything in programming. There's a lot of debug info when certain calls fail that can be useful while debugging but that is not so useful in the deployment stage. Think of it as the equivalent of setting the logging level to LOG_DEBUG in syslogd.conf and it should make a lot more sense.
My point was that you can write basic PHP without any understanding of OOP. The core bits are pretty much procedural. With Javascript, even trivial string manipulation or number rounding requires you to understand OOP and dot syntax. Compare JavaScript's Math.floor(3.4) with PHP's floor(3.4), JavaScript' mystring.substr(1,3) with PHP's substr($mystring, 1, 3), etc.
As for classes in PHP, IMHO, that really depends on how big the code is. If there are units of functionality that are easily reusable, self-contained, and tend towards data structures, then classes aren't a bad idea. For short programs, though, classes often just make the code larger, harder to read, and more CPU intensive. There's a time and a place, and I use them quite a bit, but I'm also careful not to overuse them, having seen just what painful joys that leads to. :-D
In a browser. I've never seen anyone use JavaScript as a general-purpose language.... I guess you could, but it just seems like an odd choice of language with limited ability to interface to anything else.
My point about the "8" versus 8 was that there's really not much need to make a distinction between integers and strings containing exactly an integer and nothing else. You're either using an array with numeric keys and iterators or you're using it associatively. Trying to mix the two is guaranteed to be a mess in any language. Even if the language keeps them distinct, you're creating confusion.
Actually, it sort of does. JavaScript behaves a lot like PHP. If you use numeric indices, it maintains a variable called count that is one higher than the largest numerical index used. Non-numeric indices don't modify this value. However, strings that contain nothing but a number do change this value. For example:
foo = new Array();
foo['2'] = "x";
alert(foo[2]);
alert(foo.length);
Notice that not only is the value of 1 promoted to a string for dereferencing purposes, but also the string value '1' is demoted to an integer and affects the length as though you had assigned into the array with numeric keys. This change of foo.count does not occur if you use a non-numeric key (e.g. 'x' instead of '2').
Whether you promote from numbers to strings (JS) or strings to numbers (PHP) is largely an irrelevant implementation detail as long as there is exactly one string that maps onto any given numeric value (which seems to be true, at least in PHP).
Now in the more general case, arguing that for comparison purposes and similar, numbers and strings shouldn't be treated the same way... well, I tend to agree with you, but I'm afraid that ship has pretty much sailed, and it's not a very big ship, so I won't lose sleep over it.... :-) The existence of === and !== in PHP, Perl, and the like is generally good enough for when those differences really matter.
My point was that a bunch of the major classes required use of them, last I checked (particularly the TCP/IP stuff).
I disagree. PHP actually does the right thing for a web-based service, IMHO. End-user errors are useful for end users during the deployment phase. The PHP debug output messages are useful info for developers during debugging because most of the failures are caused by a typo you made five minutes earlier. They're basically two sides of the same coin. Sure, you could print your own error message with more or less info depending on whether you're in debug mode or not, but that's a good bit of extra coding effort for no real gain over the way PHP works now.
Mainly because I have a fundamental difference of opinion when it comes to return values versus exceptions. The Java folks seem to prefer the latter quite frequently. I tend to think that exceptions are for things that are truly exceptional---the equivalent to a kernel panic---something that should almost always cause the program to crash or at most, clean up and die. Thus, exceptions should never be thrown by any standard library because no library can reasonably determine what is or is not fatal to the application that calls it.
And even within application code itself, exceptions are really just a crutch so that programmers can be lazy and skip error checking throughout large blocks of their code. The result, at least in my experience, tends to be pretty much what you would expect---buggy code that crashes or misbehaves with regularity. That's not saying you can't write good code in Java, just that in my experience, that's the exception rather than the rule. No pun intended. Exceptions save a little bit of time during the coding phase, but they make it much harder to debug certain classes of problems. They're basically the Java equivalent of setjmp or GOTO---well, not quite that bad, but close.
I know, $10 answer to a fifty cent question, but....
The @ syntax is not a try/catch. PHP doesn't stop execution when it encounters errors opening files and stuff. It merely blasts a warning message to the output stream (web client). The @ operator suppresses that output. It's equivalent to sending the perror() after a failed fopen() call to /dev/null. Whether the command succeeds or fails, control still returns to your code after the statement. The @ operator merely suppresses the error message generated by PHP so that you can display a more appropriately formatted and/or more useful error message (or not display a message at all if the failure is expected). In a production environment, most people disable the warning output from PHP anyway, making it basically a no-op except during debugging.
If you folks want an argument against PHP, you're all going about it wrong. Probably the best argument against PHP is that it makes it easy to design yourself into a corner---putting code into the middle of HTML templates that suddenly needs to be able to set a header field and "whoops, that has already been sent", putting code into the middle of templates that needs to change the content up a level, and "whoops, have to add a hack over here to fix that", etc. The result is that for really simple sites, PHP is awesome, but it has real problems scaling to more complicated designs without dropping the templates (or at best, including them on the back end after you do a lot of compute processing up front to set things up, choose a template programmatically, etc.).
Or you could simply attack it for being a lot slower than C and leading to design patterns that waste lots of memory. For example, associative arrays are simple and easy to use, but 90% of the time, there are much simpler data structures that can do just as well. If your data structures are small, no problem. If you deal with something big, the difference in memory pressure between a clean, lightweight binary tree (even without balancing) and an associative array can result in an order of magnitude impact in performance (or two or three).