You mean it is change for the sake of change (and a high-res image)?
Piss off the users who are already used to doing things a certain way, make them learn a different way. All this just to support a higher resolution image? And I doubt that higher resolution image is hindered by configuration data written in menu.lst / grub.conf. How does/etc/grub.d/40_custom help in the higher resolution image?
It's really not a big deal.
Why is it not a big deal? To make the user learn a new way, it has to be a big deal i.e. it should come with significant improvement in user experience.
Give it time (of the order of a few minutes), and the human eye adapts reasonably well to darkness. The bad guy can notice that this area is generally dark - conceal himself in it at an appropriate time, wait for a while for his eyes to adjust. As long as he mostly looks within this dark area, he will be able to see enough to handle himself.
But normal people or security guards casually/briefly glancing at that place will not see anything - because they spent most of their last few minutes looking at well-lit areas so their eyes are adjusted to a lot more light.
Result - bad guys able to remain active in the dark place undetected for some time . This may or may not be dangerous depending on the location of the dark place.
But we are talking about National Parks, aren't we? I am not much of an outdoors person, but I guess one of the ideas of National Parks is that visitors are not supposed to hurt the animals / vegetation / insects etc. in the National Park. So do they let you carry guns/pistols while roaming the National Park? Even if they know the bears don't attack humans until provoked?
Because pretty much every single example that's been used about how dangerous speeding is, has referred to pedestrians being killed. The only reasonable conclusion seems to be that the discussion is about high pedestrian areas, since they generally aren't waltzing out onto arterial roads and freeways without looking.
But not a single example mentioned anything about high-volume pedestrian areas. That addition can surely be attributed to your own ingenuity. And sure, roads (in Middle-East, and everywhere else too) can be classified into arterial roads, freeways, and completely pedestrian free roads. Thanks, I was not aware of that.
The focus on nearly the entire discussion in this, and other, threads has been about danger to pedestrians. If that doesn't imply a pedestrian-dense area, I don't know what does.
I repeat - pedestrians exist in non-pedestrian-dense areas.
I never said high speed wasn't a hazard.
May I remind you of your statement
Speeding is an incidental problem here. You're not going to save many lives when people are just plain reckless, especially when pedestrians are involved. You're as dead being hit by a car at 80km/h as you are at 120 - it's purely a matter of luck at that stage.
?
To this, I replied that speed does add to chances of drivers not noticing pedestrians, and being unable to stop once they notice pedestrians. It is not an incidental problem. You are yet to address the arguments I made for this.
No. Inattentiveness is the cause of not noticing a pedestrian.
Your inattentiveness to my post is the cause of not noticing my arguments that described how speeding causes a driver to not notice a pedestrian.
If a driver doesn't see a pedestrian, it's because he's not paying attention, or doing something else wrong.
To ignore those *critical* factors and focus solely on speed
I do not focus solely on speed. If my post did, it was because you dismissed (high) speed as a significant factor that causes accidents. It is called staying relevant to the subject.
describing a situation where only vehicles traveling at the speed you think they should be are "safe", and anyone else is "dangerous".
I don't say that. I say - the slower you drive (other things remaining constant) - the safer it would be for the kind of accidents that were being discussed. Again, reasons are mentioned in my post. You have not addressed those reasons yet.
In fact that "conclusion" is not rational at all.
It is when the only argument you're trying to make is "slower == safer".
I still don't see how "every car having someone in front of it waving a flag and ringing a bell" is rational.
I just want to prove that however inconvenient it may sound, high speed does increase number and intensity of accidents.
If that were true then the fastest roads would be the most dangerous and have the most accidents. Neither of these things are true.
High speed increases the "number and intensity of accidents", but so do a variety of other factors too. Since we are discussing speed, I do not mention them for fear of writing a multi-thousand-page book on Slashdot. In addition to reading a post before replying, you desperately need a Logic 101 course -
Factor A increases the chance of event X - does not mean that maximizing factor A maximizes the chance of event X. Because other factors B, C and D also increase/decrease the chance of event X which are not currently under discussion.
However, you are missing the main point that speed is not the primary factor in urban related accidents.
I am not missing that point - actually that is a separate point altogether. We were discussing speed limits and their arbitrariness. There surely are other, more important factors in accidents. But why bring that while discussing speed and speed limits?
Now, city administrations are fond of speed limits for various reasons. You know them all, so I'll just very briefly mention them 1. Easy to put speed limit signs. 2. Good source of revenue - occasionally place cops with speed determining machine and collect a handy sum. 3. After the accident - easy to blame the driver. Generally forensics can give an idea about the speed of the vehicle after the accident. 4. After the fact of the accident (say, fatal) - it is easy to lament that if the vehicle were any slower the accident would not have been fatal.
I could issue more tailgating, impeding traffic, and failure to yield tickets in one day than I could speeding tickets in a month.
Completely agree in a perfect world. But all these traffic offences are a lot more difficult to monitor by dumb people and dumb machines. How do you propose to hand out convincing tickets? Hiring thousands more smart cops in a million-strong city might be out of budget. So, the smaller but easier to solve problem gets the emphasis. Now, where have I heard that before:) ?
If you don't notice someone until they're 20 feet away
Well, my bad. I chose a very short distance as an example - though none of my points depended upon this figure. Say 100 or 200 feet. In fact stopping is not always necessary to save the day - once sufficiently slow and controlled you may be able to swerve. Again, lower speed - lower danger, more time to react and less panic - keep the mind working.
Secondly, because driving 80km/h in high-volume pedestrian areas isn't speeding, it's recklessly dangerous driving. People prepared to do that are not thinking rationally enough to be deterred by a fine.
Nobody here is talking about "high-volume pedestrian areas". No idea where you brought that from. I hope you are not trying to imply that only pedestrians on "high-volume pedestrian areas" are entitled to safety.
People prepared to do that are not thinking rationally enough to be deterred by a fine.
Well, that is fine. I was replying to your dismissal of (high) speed as a hazard.
Thirdly, because my comment was based on the assumption of hitting a pedestrian at that speed.
I know that, but that is an impractical assumption. In an overwhelming majority of cases, the driver would know that he is going to hit a pedestrian at least a few milli-seconds before actually hitting. Even if he does not notice this until after hitting - high speed may be a cause of this not noticing. That is what my post described - not sure if you read it to understand or just to rebut on irrelevant points. The story should start from the point when he does notice, and reasons why he notices late or not at all. So in fact, it is your assumption that is artificial.
I don't remember mentioning any child or a ball.
Finally, because the only rational conclusion to your argument is that we return to the system of every car having someone in front of it waving a flag and ringing a bell.
In fact that "conclusion" is not rational at all. I just want to prove that however inconvenient it may sound, high speed does increase number and intensity of accidents.
While exact speed maybe immaterial for many accidents, but in a case where the driver notices the pedestrian at a 20 feet distance :
1. At higher speeds, it is difficult to notice things, because more things are passing you per unit time. There comes a limit of speed of observing your surroundings - it is different for different people in different states of mind. So maybe one would notice the pedestrian at 20 feet distance if driving at 80km/h, but at 17 feet distance when driving at 120 km/h in otherwise similar conditions.
2. Lot of safe driving is anticipation. E.g. there is a cross-road meeting your highway - expect someone slightly careless to come from that cross-road. The faster you go, the less time to notice the cross-road and prepare for it. The faster such observations have to be made, the less concentration is spared for a pedestrian 20 feet away from the driver.
3. Stopping distance obviously increases by speed. I think you already know the details here.
You missed the GP's point. It is obviously arbitrary - because there is no way to precisely determine how much speed you can handle at all times on this particular stretch of road. That includes all of your own states of mind(angry, frustrated, lust-sick etc.), and all the states of the road (trafficky, dark, pedestrian-y at particular times). Even if they did determine that, the speed limit would be different for different people at different times. Such signs which read differently to different people would be difficult to put up.
So we go to some conservatively (and arbitrarily, of necessity) defined speed limits - same for everyone at all times. Conservatively because a particular bigshot's haste is less important than someone's life. Since these speed limits depend on the official in charge and is subjective - at some places you would find the speed limits less suffocating than others. This is only to be expected. I don't see you providing a solution either.
Come to think of it - that the society lets most of its people drive is itself an arbitrary decision. Since so many people die every year of road accidents, the society could easily have decided that only "Government"-trained, dedicated drivers will be allowed to chauffeur everyone around. But the value of letting most people drive was considered greater than the few lives that would (perhaps) be saved this way. But then, the privilege of driving license comes with some restrictions. Speed limit is one of them. Others are the chemicals you are allowed to have in your body (again arbitrarily decided), state of your car to be declared fit for driving (same) etc.
1. You are the awesome combination of arrogance and ignorance (of the issue being discussed). 2. The original poster is just asking for the first camera.
I'd like to add: 1. In "Middle-East", a city with a few million people typically does not have thousands of traffic signals, let alone thousands of "important" traffic signals. Cities in Middle-East (and most of Asia except extreme North Asia e.g. Russian part) are much-much more densely populated than a typical US / Canadian city. It is very likely that concentrating the effort on about 5 signals would deliver great results to start with. Because maybe 60% of the traffic passes through those 5 signals.
2. Since it is kind of volunteer-work - why would you expect him to "hire" people for maintenance? If some camera malfunctions, people would notice (maybe it sends SOS signals, maybe some volunteer monitors periodically, whatever), volunteer goes and fixes it, or sends or takes a technician there and pays him ad-hoc. Maybe there are delays in repair of the camera - but it is still better than now because there is no camera to malfunction and be repaired.
You are not only immensely exaggerating the magnitude of the problem, you are also by far over-emphasizing the need for "perfect" solution.
But unfortunately, Google is pretty good at fighting (and beating) noise. That is why so many people use Google as their one-and-only search engine.
And forums (especially those which have a significant effect on Google results) have started to have pretty good captcha technology, and spam detection and elimination technology - in some cases powered by Google itself.
if a commitment to privacy results in more customers, or a perceived lack of one results in less customers, than a privacy policy directly translates into dollars, plus or minus, at some point
But the statement, though true, does not mean much, because the predicate (a commitment to privacy results in more customers...) is expressly false. Number of facebook users, amount of time they spend on facebook, amount of personal information they put on facebook and facebook's privacy policy together proves it.
I ask you to provide an example of single socialistic government in existence that does not control all aspects of the country, including, education, distribution, and production.
I know the intricate details of Linux, but don't want to be bothered by them, so I choose to use Ubuntu.
Then you won't know many intricate details of Linux after some time. Linux is very dynamic, and people not keeping in touch with the developments lose their "expertise". Maybe some essentials remain constant - but knowledge enough to be able to debug and troubleshoot is mostly lost within 1 or 2 years. Not that it is necessarily undesirable - maybe you don't care, which is fine.
Though your C, python case is right - C is not that dynamic.
When the law makes it a crime to have THC metabolites in your body while engaging in a lawful activity the law has effectively made it illegal to have THC in your system.
No, because the driving license was provided to you on the condition that you will not have THC metabolites in your body while driving. So the activity (driving) is lawful only under certain conditions which are being broken in your example.
But you're missing the fact that, from the bird's perspective, it's simply reality. It's not augmented, it's part of it.
I am (almost) with you.
If you and I strap on a device which gives us the same vision as a bird that can see magnetic fields, that is augmented reality
No, this is also reality. You have only augmented your vision, but the reality was always there for the beholder to behold. If humans couldn't perceive it, that does not change that "reality".
So, augmented reality is when you wear a device on your eyes that make you see ugly women as hot. Since ugly and hot are too subjective - let's take another example. A device that "labels" things - someone "sees" you with that device and he also sees a "label" on your head saying : gstoddart, slashdot ID 321705. That is augmented reality. Because there is no label on your head - this is the reality. But the perceiver sees it - that is the augmentation.
"feeders" being the key word. What do they feed on? Stuff falling from a vibrant ecosystem from the upper layers of the sea. Which is no more that vibrant because of the spill. So nothing nutritious falling for the bottom feeders to eat.
They are not compulsory for everyone to use. Use the simple features if you are scared of the advanced ones. There is always BASIC, or LOGO. Advanced functionality will not be available then, but that is only to be expected.
No no. I am asking to borrow their money only. But I am saying - lend me money because I am rich. Kind of what my credit history would have said too. Even with credit history, there is no guarantee that I'll pay back this particular debt.
Secured credit cards is a totally different beast. Here, the lender has an absolute certainty of not losing his money. Like you, I am also not talking about this beast.
Every syntax is about convenience/terseness. Otherwise go to binary code directly.
In the sense I used the word convenience (less typing for the programmer) - I strongly disagree. (Hence) also strongly disagree for terseness.
(I'll replace binary with assembly from now on, because binary is absolutely useless for developing code.)
At times compiled code might be longer than assembly code, but programmers might still find it easier to work with higher level language than assembly code. 1. Higher level languages expose coding ideas to programmers which is easier to relate to / understand. 2. It reduces repetitive work, but might introduce extra cruft (e.g. variable declarations). 3. It also makes it easier to make the code more maintainable. E.g. change a constant at one place and have a lot of functionality reflect the change. Or comment out some code for the time being. 4. And in java's case, the language is also hiding platform specific complications from the programmer. In a round-about way, yes, it prevents the user from having to type code separately for each platform. But in this case, higher level language is mainly helpful because modifying code for each platform is repetitive work and humans are not good at it.
I was talking about matching the exception chain that results from deeply nested exceptions. In several cases for correct recovery, you must traverse the exception chain, but some syntax sugar could really help here.
I don't think you have a solution here.
I just don't want to repeat the same handling pattern every time but I want it to refactor it to one place. I stumbled many times into problems, when the handling/recovery part was almost the same, but with one parameter changing. In this case your best bet is to factor out some of the handler part into a method (or sometimes it's own class) and call it from the catch blocks. But the try..catch clutter will remain. Don't repeat yourself is violated here.
Very true. I was very perplexed with java (1.3)'s way of doing things when I first got into such a scenario 7 years ago. I was coming from perl and C coding - where I would have used function pointers to solve this problem very elegantly. The try..catch block goes into the function for which I use pointers in all the handling places. Arguments to this functions control its behaviour.
But it was a harsh discovery for me that java does not have function pointers. The "replacement" is 1. Reflection : Performance is awful. And it has its own complicated syntax. 2. Now closures are coming. I think this is the syntactic sugar you are want. Though not exactly what you are asking for.
"IDE functionality. Java just provides a way to wrap. Doing it en-masse on the class is a problem of your IDE."
First of all, you cannot delegate every important stuff to the IDE. It makes sense in many cases, but not every time. Also, if I could declare the rethrow case at the beginning of the class, it would make the code more readable. Again, I am talking about syntax.
If you have followed Java languages' progress, you would have lost hope for terse constructs long ago. Like I did. Java designers' argument has always been that coding has to be done in an IDE. While I don't agree with this position, Java still seems to be the best bet for many situations, so I have come to accept it.
Readability: IDE helps there too. Just have it to collapse unnecessary code automatically and open only when you need it. It is not Java's way (TM) to reduce verbosity to enhance readability. According to anthropomorphized Java, that is what an IDE is for. But I guess closures is the solution from Java's side in this case too.
I am not an American, but can't they do this : Check my bank balance history. They could ask for other measures of "net worth certificate" - such certificates might be a set of investment certificates. These are required only if the "credit history" does not store such information. The credit history will tell them that there is no liability.
I don't see a problem. Someone was not aware of the "capture-of" concept and it was explained to him. Simple concept, and explained well. I myself was a bit rusty on it, but got on with it quickly on reading this explanation.
I don't understand. Your other post seems almost to be arguing for java type exception handling. All those idioms are well supported in java.
Only thing that java does not have is convenience/terseness. But the java language designers have long held that coding must be done in an IDE and it is the IDE's problem if user is having to type a lot, or having to hand-code complicated but well-known idioms. I can't say I completely agree, but in that case, you should say that your only problem with java exception handling is having to use a good IDE.
pattern matching on nested exceptions
If you mean string pattern matching, I am horrified at the disaster that it will be. But yeah, object patterns can and are matched in java exception handling.
try {
throw new java.sql.SQLException(); }catch(Exception e) {// pattern has been matched. Since SQLException is a kind of "Exception". }
- declaring that a class will simply wrap and rethrow all exceptions in a given higher level exception
IDE functionality. Java just provides a way to wrap. Doing it en-masse on the class is a problem of your IDE.
implementing common exception handler routines in a separate class and declaratively attaching them to other classes - AOP style would be handy
This is true. Though I don't see why you would do AOP style coding for exception handling. While developing code, a developer is most aware of the exceptional circumstances each code fragment can run into. Especially with the generous use of checked exceptions in java. If the exception handling "aspect" is left to another day, many exceptions would be missed. If they have to be done together, coder would needlessly have to alternate between business logic aspect and the exception handling aspect. This is the undesirable decoupling of 2 things that go together.
chaining attached handlers
I don't know what you mean by this. Is it an instance of partly handle, wrap, rethrow? If so, same argument. Verbose but supported.
package level declarations about the exception types that could be thrown to classes outside the package
Could be interesting. Any concrete example where this information would be useful? And how would the compiler / execution engine use it? It can't force the client developer to catch in all methods each of the exceptions that a package was going to throw, right?
PS: And the verbosity/inconvenience is not just a problem with exception handling in java. Method calling with named parameter passing is also something java does not have. It is not needed if you code with IDEs, but for less powerful editors, it would have been extremely useful.
E.g. computeExponent(base=8, exponent=2) == 64
computeExponent(8,2) is just too confusing and prone to error.
Slashdot Mirror
You mean it is change for the sake of change (and a high-res image)?
Piss off the users who are already used to doing things a certain way, make them learn a different way. All this just to support a higher resolution image? And I doubt that higher resolution image is hindered by configuration data written in menu.lst / grub.conf. How does /etc/grub.d/40_custom help in the higher resolution image?
It's really not a big deal.
Why is it not a big deal? To make the user learn a new way, it has to be a big deal i.e. it should come with significant improvement in user experience.
Give it time (of the order of a few minutes), and the human eye adapts reasonably well to darkness. The bad guy can notice that this area is generally dark - conceal himself in it at an appropriate time, wait for a while for his eyes to adjust. As long as he mostly looks within this dark area, he will be able to see enough to handle himself.
But normal people or security guards casually/briefly glancing at that place will not see anything - because they spent most of their last few minutes looking at well-lit areas so their eyes are adjusted to a lot more light.
Result - bad guys able to remain active in the dark place undetected for some time . This may or may not be dangerous depending on the location of the dark place.
But we are talking about National Parks, aren't we? I am not much of an outdoors person, but I guess one of the ideas of National Parks is that visitors are not supposed to hurt the animals / vegetation / insects etc. in the National Park. So do they let you carry guns/pistols while roaming the National Park? Even if they know the bears don't attack humans until provoked?
Apparently, humans are not that tasty.
Because pretty much every single example that's been used about how dangerous speeding is, has referred to pedestrians being killed. The only reasonable conclusion seems to be that the discussion is about high pedestrian areas, since they generally aren't waltzing out onto arterial roads and freeways without looking.
But not a single example mentioned anything about high-volume pedestrian areas. That addition can surely be attributed to your own ingenuity. And sure, roads (in Middle-East, and everywhere else too) can be classified into arterial roads, freeways, and completely pedestrian free roads. Thanks, I was not aware of that.
The focus on nearly the entire discussion in this, and other, threads has been about danger to pedestrians. If that doesn't imply a pedestrian-dense area, I don't know what does.
I repeat - pedestrians exist in non-pedestrian-dense areas.
I never said high speed wasn't a hazard.
May I remind you of your statement
Speeding is an incidental problem here. You're not going to save many lives when people are just plain reckless, especially when pedestrians are involved. You're as dead being hit by a car at 80km/h as you are at 120 - it's purely a matter of luck at that stage.
?
To this, I replied that speed does add to chances of drivers not noticing pedestrians, and being unable to stop once they notice pedestrians. It is not an incidental problem. You are yet to address the arguments I made for this.
No. Inattentiveness is the cause of not noticing a pedestrian.
Your inattentiveness to my post is the cause of not noticing my arguments that described how speeding causes a driver to not notice a pedestrian.
If a driver doesn't see a pedestrian, it's because he's not paying attention, or doing something else wrong.
To ignore those *critical* factors and focus solely on speed
I do not focus solely on speed. If my post did, it was because you dismissed (high) speed as a significant factor that causes accidents. It is called staying relevant to the subject.
describing a situation where only vehicles traveling at the speed you think they should be are "safe", and anyone else is "dangerous".
I don't say that. I say - the slower you drive (other things remaining constant) - the safer it would be for the kind of accidents that were being discussed. Again, reasons are mentioned in my post. You have not addressed those reasons yet.
In fact that "conclusion" is not rational at all.
It is when the only argument you're trying to make is "slower == safer".
I still don't see how "every car having someone in front of it waving a flag and ringing a bell" is rational.
I just want to prove that however inconvenient it may sound, high speed does increase number and intensity of accidents.
If that were true then the fastest roads would be the most dangerous and have the most accidents. Neither of these things are true.
High speed increases the "number and intensity of accidents", but so do a variety of other factors too. Since we are discussing speed, I do not mention them for fear of writing a multi-thousand-page book on Slashdot. In addition to reading a post before replying, you desperately need a Logic 101 course -
Factor A increases the chance of event X - does not mean that maximizing factor A maximizes the chance of event X. Because other factors B, C and D also increase/decrease the chance of event X which are not currently under discussion.
thanks
However, you are missing the main point that speed is not the primary factor in urban related accidents.
I am not missing that point - actually that is a separate point altogether. We were discussing speed limits and their arbitrariness. There surely are other, more important factors in accidents. But why bring that while discussing speed and speed limits?
Now, city administrations are fond of speed limits for various reasons. You know them all, so I'll just very briefly mention them
1. Easy to put speed limit signs.
2. Good source of revenue - occasionally place cops with speed determining machine and collect a handy sum.
3. After the accident - easy to blame the driver. Generally forensics can give an idea about the speed of the vehicle after the accident.
4. After the fact of the accident (say, fatal) - it is easy to lament that if the vehicle were any slower the accident would not have been fatal.
I could issue more tailgating, impeding traffic, and failure to yield tickets in one day than I could speeding tickets in a month.
Completely agree in a perfect world. But all these traffic offences are a lot more difficult to monitor by dumb people and dumb machines. How do you propose to hand out convincing tickets? Hiring thousands more smart cops in a million-strong city might be out of budget. So, the smaller but easier to solve problem gets the emphasis. Now, where have I heard that before :) ?
If you don't notice someone until they're 20 feet away
Well, my bad. I chose a very short distance as an example - though none of my points depended upon this figure. Say 100 or 200 feet. In fact stopping is not always necessary to save the day - once sufficiently slow and controlled you may be able to swerve. Again, lower speed - lower danger, more time to react and less panic - keep the mind working.
Secondly, because driving 80km/h in high-volume pedestrian areas isn't speeding, it's recklessly dangerous driving. People prepared to do that are not thinking rationally enough to be deterred by a fine.
Nobody here is talking about "high-volume pedestrian areas". No idea where you brought that from. I hope you are not trying to imply that only pedestrians on "high-volume pedestrian areas" are entitled to safety.
People prepared to do that are not thinking rationally enough to be deterred by a fine.
Well, that is fine. I was replying to your dismissal of (high) speed as a hazard.
Thirdly, because my comment was based on the assumption of hitting a pedestrian at that speed.
I know that, but that is an impractical assumption. In an overwhelming majority of cases, the driver would know that he is going to hit a pedestrian at least a few milli-seconds before actually hitting. Even if he does not notice this until after hitting - high speed may be a cause of this not noticing. That is what my post described - not sure if you read it to understand or just to rebut on irrelevant points. The story should start from the point when he does notice, and reasons why he notices late or not at all. So in fact, it is your assumption that is artificial.
I don't remember mentioning any child or a ball.
Finally, because the only rational conclusion to your argument is that we return to the system of every car having someone in front of it waving a flag and ringing a bell.
In fact that "conclusion" is not rational at all. I just want to prove that however inconvenient it may sound, high speed does increase number and intensity of accidents.
While exact speed maybe immaterial for many accidents, but in a case where the driver notices the pedestrian at a 20 feet distance :
1. At higher speeds, it is difficult to notice things, because more things are passing you per unit time. There comes a limit of speed of observing your surroundings - it is different for different people in different states of mind. So maybe one would notice the pedestrian at 20 feet distance if driving at 80km/h, but at 17 feet distance when driving at 120 km/h in otherwise similar conditions.
2. Lot of safe driving is anticipation. E.g. there is a cross-road meeting your highway - expect someone slightly careless to come from that cross-road. The faster you go, the less time to notice the cross-road and prepare for it. The faster such observations have to be made, the less concentration is spared for a pedestrian 20 feet away from the driver.
3. Stopping distance obviously increases by speed. I think you already know the details here.
Now, how is that "purely a matter of luck" here ?
You missed the GP's point. It is obviously arbitrary - because there is no way to precisely determine how much speed you can handle at all times on this particular stretch of road. That includes all of your own states of mind(angry, frustrated, lust-sick etc.), and all the states of the road (trafficky, dark, pedestrian-y at particular times). Even if they did determine that, the speed limit would be different for different people at different times. Such signs which read differently to different people would be difficult to put up.
So we go to some conservatively (and arbitrarily, of necessity) defined speed limits - same for everyone at all times. Conservatively because a particular bigshot's haste is less important than someone's life. Since these speed limits depend on the official in charge and is subjective - at some places you would find the speed limits less suffocating than others. This is only to be expected. I don't see you providing a solution either.
Come to think of it - that the society lets most of its people drive is itself an arbitrary decision. Since so many people die every year of road accidents, the society could easily have decided that only "Government"-trained, dedicated drivers will be allowed to chauffeur everyone around. But the value of letting most people drive was considered greater than the few lives that would (perhaps) be saved this way. But then, the privilege of driving license comes with some restrictions. Speed limit is one of them. Others are the chemicals you are allowed to have in your body (again arbitrarily decided), state of your car to be declared fit for driving (same) etc.
While others have already pointed out that:
1. You are the awesome combination of arrogance and ignorance (of the issue being discussed).
2. The original poster is just asking for the first camera.
I'd like to add:
1. In "Middle-East", a city with a few million people typically does not have thousands of traffic signals, let alone thousands of "important" traffic signals. Cities in Middle-East (and most of Asia except extreme North Asia e.g. Russian part) are much-much more densely populated than a typical US / Canadian city. It is very likely that concentrating the effort on about 5 signals would deliver great results to start with. Because maybe 60% of the traffic passes through those 5 signals.
2. Since it is kind of volunteer-work - why would you expect him to "hire" people for maintenance? If some camera malfunctions, people would notice (maybe it sends SOS signals, maybe some volunteer monitors periodically, whatever), volunteer goes and fixes it, or sends or takes a technician there and pays him ad-hoc. Maybe there are delays in repair of the camera - but it is still better than now because there is no camera to malfunction and be repaired.
You are not only immensely exaggerating the magnitude of the problem, you are also by far over-emphasizing the need for "perfect" solution.
It's the difference, actually, between Christians and Muslims. Yes, I've lived in both.
I have never figured out how to live in a Christian or a Muslim. Entering them for a while is fine, but live inside them? Sounds crazy.
Noise is google's enemy.
But unfortunately, Google is pretty good at fighting (and beating) noise. That is why so many people use Google as their one-and-only search engine.
And forums (especially those which have a significant effect on Google results) have started to have pretty good captcha technology, and spam detection and elimination technology - in some cases powered by Google itself.
if a commitment to privacy results in more customers, or a perceived lack of one results in less customers, than a privacy policy directly translates into dollars, plus or minus, at some point
I completely agree, because
( if(false) then false ) == true
But the statement, though true, does not mean much, because the predicate (a commitment to privacy results in more customers ...) is expressly false. Number of facebook users, amount of time they spend on facebook, amount of personal information they put on facebook and facebook's privacy policy together proves it.
I ask you to provide an example of single socialistic government in existence that does not control all aspects of the country, including, education, distribution, and production.
India, as of 1960s.
I know the intricate details of Linux, but don't want to be bothered by them, so I choose to use Ubuntu.
Then you won't know many intricate details of Linux after some time. Linux is very dynamic, and people not keeping in touch with the developments lose their "expertise". Maybe some essentials remain constant - but knowledge enough to be able to debug and troubleshoot is mostly lost within 1 or 2 years. Not that it is necessarily undesirable - maybe you don't care, which is fine.
Though your C, python case is right - C is not that dynamic.
When the law makes it a crime to have THC metabolites in your body while engaging in a lawful activity the law has effectively made it illegal to have THC in your system.
No, because the driving license was provided to you on the condition that you will not have THC metabolites in your body while driving. So the activity (driving) is lawful only under certain conditions which are being broken in your example.
But you're missing the fact that, from the bird's perspective, it's simply reality. It's not augmented, it's part of it.
I am (almost) with you.
If you and I strap on a device which gives us the same vision as a bird that can see magnetic fields, that is augmented reality
No, this is also reality. You have only augmented your vision, but the reality was always there for the beholder to behold. If humans couldn't perceive it, that does not change that "reality".
So, augmented reality is when you wear a device on your eyes that make you see ugly women as hot. Since ugly and hot are too subjective - let's take another example. A device that "labels" things - someone "sees" you with that device and he also sees a "label" on your head saying : gstoddart, slashdot ID 321705. That is augmented reality. Because there is no label on your head - this is the reality. But the perceiver sees it - that is the augmentation.
bottom feeders
"feeders" being the key word. What do they feed on? Stuff falling from a vibrant ecosystem from the upper layers of the sea. Which is no more that vibrant because of the spill. So nothing nutritious falling for the bottom feeders to eat.
Open source. You keep using that word. I don't think it means what you think it means.
locked out of this slashdot account for 10+ years... Im back
How were you locked out?
IMO language features should be simple enough
They are not compulsory for everyone to use. Use the simple features if you are scared of the advanced ones. There is always BASIC, or LOGO. Advanced functionality will not be available then, but that is only to be expected.
No no. I am asking to borrow their money only. But I am saying - lend me money because I am rich. Kind of what my credit history would have said too. Even with credit history, there is no guarantee that I'll pay back this particular debt.
Secured credit cards is a totally different beast. Here, the lender has an absolute certainty of not losing his money. Like you, I am also not talking about this beast.
Every syntax is about convenience/terseness. Otherwise go to binary code directly.
In the sense I used the word convenience (less typing for the programmer) - I strongly disagree. (Hence) also strongly disagree for terseness.
(I'll replace binary with assembly from now on, because binary is absolutely useless for developing code.)
At times compiled code might be longer than assembly code, but programmers might still find it easier to work with higher level language than assembly code.
1. Higher level languages expose coding ideas to programmers which is easier to relate to / understand.
2. It reduces repetitive work, but might introduce extra cruft (e.g. variable declarations).
3. It also makes it easier to make the code more maintainable. E.g. change a constant at one place and have a lot of functionality reflect the change. Or comment out some code for the time being.
4. And in java's case, the language is also hiding platform specific complications from the programmer. In a round-about way, yes, it prevents the user from having to type code separately for each platform. But in this case, higher level language is mainly helpful because modifying code for each platform is repetitive work and humans are not good at it.
I was talking about matching the exception chain that results from deeply nested exceptions. In several cases for correct recovery, you must traverse the exception chain, but some syntax sugar could really help here.
I don't think you have a solution here.
I just don't want to repeat the same handling pattern every time but I want it to refactor it to one place. I stumbled many times into problems, when the handling/recovery part was almost the same, but with one parameter changing. In this case your best bet is to factor out some of the handler part into a method (or sometimes it's own class) and call it from the catch blocks. But the try..catch clutter will remain. Don't repeat yourself is violated here.
Very true. I was very perplexed with java (1.3)'s way of doing things when I first got into such a scenario 7 years ago. I was coming from perl and C coding - where I would have used function pointers to solve this problem very elegantly. The try..catch block goes into the function for which I use pointers in all the handling places. Arguments to this functions control its behaviour.
But it was a harsh discovery for me that java does not have function pointers. The "replacement" is
1. Reflection : Performance is awful. And it has its own complicated syntax.
2. Now closures are coming. I think this is the syntactic sugar you are want. Though not exactly what you are asking for.
"IDE functionality. Java just provides a way to wrap. Doing it en-masse on the class is a problem of your IDE."
First of all, you cannot delegate every important stuff to the IDE. It makes sense in many cases, but not every time. Also, if I could declare the rethrow case at the beginning of the class, it would make the code more readable. Again, I am talking about syntax.
If you have followed Java languages' progress, you would have lost hope for terse constructs long ago. Like I did. Java designers' argument has always been that coding has to be done in an IDE. While I don't agree with this position, Java still seems to be the best bet for many situations, so I have come to accept it.
Readability: IDE helps there too. Just have it to collapse unnecessary code automatically and open only when you need it. It is not Java's way (TM) to reduce verbosity to enhance readability. According to anthropomorphized Java, that is what an IDE is for. But I guess closures is the solution from Java's side in this case too.
I am not an American, but can't they do this : Check my bank balance history. They could ask for other measures of "net worth certificate" - such certificates might be a set of investment certificates. These are required only if the "credit history" does not store such information. The credit history will tell them that there is no liability.
I don't see a problem. Someone was not aware of the "capture-of" concept and it was explained to him. Simple concept, and explained well. I myself was a bit rusty on it, but got on with it quickly on reading this explanation.
I don't understand. Your other post seems almost to be arguing for java type exception handling. All those idioms are well supported in java.
Only thing that java does not have is convenience/terseness. But the java language designers have long held that coding must be done in an IDE and it is the IDE's problem if user is having to type a lot, or having to hand-code complicated but well-known idioms. I can't say I completely agree, but in that case, you should say that your only problem with java exception handling is having to use a good IDE.
pattern matching on nested exceptions
If you mean string pattern matching, I am horrified at the disaster that it will be. But yeah, object patterns can and are matched in java exception handling.
try // pattern has been matched. Since SQLException is a kind of "Exception".
{
throw new java.sql.SQLException();
}catch(Exception e)
{
}
- declaring that a class will simply wrap and rethrow all exceptions in a given higher level exception
IDE functionality. Java just provides a way to wrap. Doing it en-masse on the class is a problem of your IDE.
implementing common exception handler routines in a separate class and declaratively attaching them to other classes - AOP style would be handy
This is true. Though I don't see why you would do AOP style coding for exception handling. While developing code, a developer is most aware of the exceptional circumstances each code fragment can run into. Especially with the generous use of checked exceptions in java. If the exception handling "aspect" is left to another day, many exceptions would be missed. If they have to be done together, coder would needlessly have to alternate between business logic aspect and the exception handling aspect. This is the undesirable decoupling of 2 things that go together.
chaining attached handlers
I don't know what you mean by this. Is it an instance of partly handle, wrap, rethrow? If so, same argument. Verbose but supported.
package level declarations about the exception types that could be thrown to classes outside the package
Could be interesting. Any concrete example where this information would be useful? And how would the compiler / execution engine use it? It can't force the client developer to catch in all methods each of the exceptions that a package was going to throw, right?
PS:
And the verbosity/inconvenience is not just a problem with exception handling in java. Method calling with named parameter passing is also something java does not have. It is not needed if you code with IDEs, but for less powerful editors, it would have been extremely useful.
E.g. computeExponent(base=8, exponent=2) == 64
computeExponent(8,2) is just too confusing and prone to error.