It is pointless, in a single-user environment, where all the software was written by the same guy, with no networking, who never makes coding errors.
Admittedly that's a pretty specific use case, but it works for him. It reminds me of coding on the Amiga, back in the day. Bad pointer dereference? Oops, total OS crash and reboot, and if you're really lucky now your filesystem is corrupted and you've lost the source code you were working on. That'll teach ya...;)
Of course, C# has a much larger ecosystem, which is also kind of the point.
Of course, C# is also Microsoft's baby, which is enough to disqualify it from use inside Apple and Google all by itself. Nobody at either of those companies is going to risk relying on Microsoft's intellectual property for anything mission-critical.
All of the managers I've worked with never look at code at all. They judge performance based on whether the application works well for the customers, or not. It could be written entirely in brainf*ck for all they care, as long as it works well. (of course well-written code is more likely to work well than a badly-written mess, but that insight is left to the coders to realize, or not)
The "flat" looks with 16 colors are a step backwards, trendy or not, and I include Apple with this. It looks like some sort of accessibility mode has been enabled for people with poor eyesight.
The "flat" look has been introduced as an interim step, so that they can provide a nice 3D/bevelled look in a subsequent release. Those new-features bullet-lists aren't going to write themselves, ya know!
Do you ever get the paranoid feeling that someone is occasionally modifying the laws of physics in order to advance the plot?
"Oh look, they're going to be stuck on Earth for an excruciatingly long time due to the exponential-propellent-scaling problem. Let's add a new capability to graphene that will give them a work-around for that."
I claim that two years ago the exact same graphene experiment would have shown no unexpected results; but now in 2015 we see this suspiciously useful behavior appear. I'm not sure how to test my hypothesis though:)
Who is the one coming out asking the Congress to extend the Patriot Act?
Was it Cheney Rumsfeld Bush and Co., or was it Obama?
What kind of a dictator "asks" Congress for anything? A proper dictator would, you know, dictate his commands, and any Congressman who refused to rubber-stamp them would be fired, or shot (or both).
The only reason it's worth $200000 is because some idiot paid that much, because he's hoping that in a few years he can sell it to a bigger idiot for $250000.
Maybe that's his motivation; but it's just as likely he's trying to complete his collection of "vintage" computers and has money to burn. Not every collector is motivated solely by arbitrage.
I have yet to encounter a non-contrived example where multiple interitance is a plausible solution to a problem.
Okay, I'll give it a shot, then... here's where I find multiple inheritance not just plausible, but preferable.
I have a publish/subscribe model including an abstract-base-class/interface (call it IDataSubscriber) that can be subclassed by any object that wishes to be notified about e.g. data updates coming in from the network.
There are a number of common-case standard responses (implemented as concrete IDataSubscriber methods) to those data updates that are useful for many situations, and I don't want to have to have to rewrite them separately for every subclass, so I make a concrete or almost-concrete subclass (e.g. StandardDataSubscriber) that contains this common logic.
Finally, in my client code (based on Qt) I have a number of GUI widgets based on QWidget or QPushButton or whatever. I want these widgets to react to published data in the standard way, so I often end up with this:
class MyButton : public QPushButton, public StandardDataSubscriber {...}
... and it handles my needs nicely. It's also possible to do the same thing with "just" single inheritance and interfaces as well, or with Qt's signals-and-slots, but AFAICT do to it that way you end up having to do lots of manual method-call-forwarding through proxy objects (or, alternatively, lots of manual signal/slot connecting), which is less efficient, harder to read/understand, and more error-prone.
So yeah, it's not as easy as just throwing a GPS on your locomotive and calling it good.
Still, even a partial solution (e.g. one that matches the train's GPS location, if known, against a table of specified maximum-safe-under-any-circumstances speed limits for that location) would prevent a train wreck in certain cases (such as the recent one that prompted this article). I'm all for full PTC, but I don't think the perfect needs to be made the enemy of the good here.
If the engineers' concentration is so fragile that they are going to be distracted by a camera, they are obviously not the right people to be operating complex machinery.
They suffer from a condition called "being human". It causes occasional failures in an otherwise operational controller-human, some very small percentage of the time. Even the highest-quality controller-humans have a non-zero failure rate.
Maybe we should just replace them with automation and run the trains remotely. They could keep one engineer per train to engage the manual override in the event that someone hacks the control infrastructure and tries to do Bad Things(tm) to the trains.
That is actually a pretty good idea, and it's more or less what PTC is intended to do, at least as far as the "avoid accidents" part of the job is concerned. Automating things further than that is also possible, although probably not really necessary.
Not only that, the dough likely came from multiple different stalks of wheat, and the sauce was derived from a number of tomato vines. I'm not sure how any of this is relevant to the quality of the pizza, though.
People looking at the car have to be able to tell that that car is an electric vehicle and not an ICE, in order to properly appreciate how the EV owner is saving the planet. By making it ugly, they can also allow the owner to sacrifice further by not driving a good looking car.
That's the cynical answer.
The actual reason that EV cars often look strange is because the designers are trying to make them as aerodynamic as possible in order to extend their range.
As battery power density becomes more adequate, maximizing aerodynamic efficiency will become less of a priority, so in the future you can expect designs that make efficiency tradeoffs in order to get a better look.
There's an easy fix for that -- move to India where you can enjoy extremely cheap goods and services.
(or if that doesn't sound like an appealing option to you, ask yourself why it is you find it preferable to live in the USA despite the higher cost of living)
Slashdot Mirror
Like thinking memory protection is pointless?
It is pointless, in a single-user environment, where all the software was written by the same guy, with no networking, who never makes coding errors.
Admittedly that's a pretty specific use case, but it works for him. It reminds me of coding on the Amiga, back in the day. Bad pointer dereference? Oops, total OS crash and reboot, and if you're really lucky now your filesystem is corrupted and you've lost the source code you were working on. That'll teach ya... ;)
I understand that Siri only gets paid 76.5% of what Clippy gets. That hardly seems fair.
What Clippy gets is a good swift kick in the pants. Siri should count herself lucky to only get 76.5% of that.
How are you guys OK with this? Like, what discourse goes through your mind to justify this when you are forced to pull out the credit card?
It's a cost of doing business? If you think Apple is bad, try developing games for Nintendo.
you're cramming in more and more functions into an increasingly small case, so more is more difficult and considered by some to be more admirable.
I know a number of software developers who think along these same lines... ;)
We will be required to be sober and attentive even if not driving.
Also, please do not vomit on the upholstery.
Of course, C# has a much larger ecosystem, which is also kind of the point.
Of course, C# is also Microsoft's baby, which is enough to disqualify it from use inside Apple and Google all by itself. Nobody at either of those companies is going to risk relying on Microsoft's intellectual property for anything mission-critical.
All of the managers I've worked with never look at code at all. They judge performance based on whether the application works well for the customers, or not. It could be written entirely in brainf*ck for all they care, as long as it works well. (of course well-written code is more likely to work well than a badly-written mess, but that insight is left to the coders to realize, or not)
Every state in the United States has the same set of laws banning anyone from selling new cars except members of the Dealer Cartel.
And yet somehow Teslas are being sold, despite the fact that Tesla does not partner with the Dealer Cartel. How do they manage?
The "flat" looks with 16 colors are a step backwards, trendy or not, and I include Apple with this. It looks like some sort of accessibility mode has been enabled for people with poor eyesight.
The "flat" look has been introduced as an interim step, so that they can provide a nice 3D/bevelled look in a subsequent release. Those new-features bullet-lists aren't going to write themselves, ya know!
If 5% of the population did this the entire system would grind to a halt.
... and if there's one thing that air travelers look forward to experiencing, it's being in an airport when the entire system grinds to a halt. :)
Do you ever get the paranoid feeling that someone is occasionally modifying the laws of physics in order to advance the plot?
"Oh look, they're going to be stuck on Earth for an excruciatingly long time due to the exponential-propellent-scaling problem. Let's add a new capability to graphene that will give them a work-around for that."
I claim that two years ago the exact same graphene experiment would have shown no unexpected results; but now in 2015 we see this suspiciously useful behavior appear. I'm not sure how to test my hypothesis though :)
First they came for the buggy whip producers, and I said nothing...
... under the dictatorship of Obama ...
Who is the one coming out asking the Congress to extend the Patriot Act?
Was it Cheney Rumsfeld Bush and Co., or was it Obama?
What kind of a dictator "asks" Congress for anything? A proper dictator would, you know, dictate his commands, and any Congressman who refused to rubber-stamp them would be fired, or shot (or both).
The only reason it's worth $200000 is because some idiot paid that much, because he's hoping that in a few years he can sell it to a bigger idiot for $250000.
Maybe that's his motivation; but it's just as likely he's trying to complete his collection of "vintage" computers and has money to burn. Not every collector is motivated solely by arbitrage.
No need for guns; just station a half-dozen guard birds on the roof.
I have yet to encounter a non-contrived example where multiple interitance is a plausible solution to a problem.
Okay, I'll give it a shot, then... here's where I find multiple inheritance not just plausible, but preferable.
I have a publish/subscribe model including an abstract-base-class/interface (call it IDataSubscriber) that can be subclassed by any object that wishes to be notified about e.g. data updates coming in from the network.
There are a number of common-case standard responses (implemented as concrete IDataSubscriber methods) to those data updates that are useful for many situations, and I don't want to have to have to rewrite them separately for every subclass, so I make a concrete or almost-concrete subclass (e.g. StandardDataSubscriber) that contains this common logic.
Finally, in my client code (based on Qt) I have a number of GUI widgets based on QWidget or QPushButton or whatever. I want these widgets to react to published data in the standard way, so I often end up with this:
class MyButton : public QPushButton, public StandardDataSubscriber {...}
Maybe this will finally shut up the people who complain that eBooks just aren't like the real thing.
and you wonder why California has no money for the basics.
Actually, California is doing pretty well at the moment.
(Come to think of it, a good 10% the readership of this site probably REALLY does want a pony.)
Dibs on Twilight Sparkle! :)
So, how do the "poorest residents" own a home?
Most likely they bought back when housing prices were cheaper and/or they had more income.
Prop 13 at work, eh?
So yeah, it's not as easy as just throwing a GPS on your locomotive and calling it good.
Still, even a partial solution (e.g. one that matches the train's GPS location, if known, against a table of specified maximum-safe-under-any-circumstances speed limits for that location) would prevent a train wreck in certain cases (such as the recent one that prompted this article). I'm all for full PTC, but I don't think the perfect needs to be made the enemy of the good here.
If the engineers' concentration is so fragile that they are going to be distracted by a camera, they are obviously not the right people to be operating complex machinery.
They suffer from a condition called "being human". It causes occasional failures in an otherwise operational controller-human, some very small percentage of the time. Even the highest-quality controller-humans have a non-zero failure rate.
Maybe we should just replace them with automation and run the trains remotely. They could keep one engineer per train to engage the manual override in the event that someone hacks the control infrastructure and tries to do Bad Things(tm) to the trains.
That is actually a pretty good idea, and it's more or less what PTC is intended to do, at least as far as the "avoid accidents" part of the job is concerned. Automating things further than that is also possible, although probably not really necessary.
Ah, I see you're building a finger print database. Nice.
<Morbo>Touch screens do not work that way! Good night!</Morbo>
Not only that, the dough likely came from multiple different stalks of wheat, and the sauce was derived from a number of tomato vines. I'm not sure how any of this is relevant to the quality of the pizza, though.
People looking at the car have to be able to tell that that car is an electric vehicle and not an ICE, in order to properly appreciate how the EV owner is saving the planet. By making it ugly, they can also allow the owner to sacrifice further by not driving a good looking car.
That's the cynical answer.
The actual reason that EV cars often look strange is because the designers are trying to make them as aerodynamic as possible in order to extend their range.
As battery power density becomes more adequate, maximizing aerodynamic efficiency will become less of a priority, so in the future you can expect designs that make efficiency tradeoffs in order to get a better look.
There's an easy fix for that -- move to India where you can enjoy extremely cheap goods and services.
(or if that doesn't sound like an appealing option to you, ask yourself why it is you find it preferable to live in the USA despite the higher cost of living)