Don't trust the lighting level info you get from the video. Your eyes are a lot better at dealing withing varying light than a camera. If you had been in the car you would have seen more than you can see on the video.
The video appears to show that only the first 20m in front of the car is illuminated. The next time you drive at night, ask yourself if you can only see 20 meters ahead? I should hope not - probably you can sense movement up to 100 meters or something. I'm guessing it's the same in the Uber car, but the video camera does a bad job of capturing the shadows in the dark.
There always was a plethora of compilers on Microsofts operating systems: Watcom, Intel, Borland, Digital Mars, various gcc ports, and many others long forgotten, not to mention Microsoft's offerings.
But these days people seem to have borrowed a notion from Unix: "The platform compiler", and have gotten into their heads that Microsoft(tm) Visual Studio(tm) is just that.
But it isn't! There's no such thing! You just pick whichever compiler you feel feeds the needs of your project. For all the things that suck about Windows development, this is not one of them. There's choice and competition and that is a thing to rejoice about. Do not succumb to the fallacy that because Linux is good, then the cathedral of Linux compiler monoculture is also good.
And yes, I realise that a lot of these compilers also run on Linux, including Clang, which is sort of the point of the article. I'm just ranting because I'm getting sick and tired of OSS projects that on Windows only works with the latest edition of Microsoft(tm) Visual Studio(tm), because that's what the lead developer happens to use, and the lead developer can't be bothered to write portable code, because apparently Windows is such a magical special case that the normal rules of good software development practices don't apply.
End of rant. Diversity good! Monoculture bad! Ugh!
Why on earth would you do that? You have the whole internet at your fingertips, and you pick the slashdot summary as your prime source of information??
Wind takes ten times the steel and concrete per installed megawatt compared to nuclear, coal, or natural gas.
There is no world-wide shortage of steel or concrete. We can make as much of that stuff as we need given sufficient energy, and the energy spent on steel and concrete is a tiny fraction of the energy produced. So, not a problem.
... assuming 1.65 MW rated output...
That's a cute little bonsai windmill you have there. Just how old is that Morgan Stanley report?
Tesla was the first modern age mass produced electric car that people thought was cool. Props for that. But they're more than a 100 years too late to lay title to the first mass produced EV. EV's were all the rage 120 years ago.
We can agree that the US as a country is not pushing against EV's. But don't you get the feeling that the US government might be? And in the context of of FAA approvals, the government is a pretty important player.
Except they're not. Per capita, high rise apartment complexes pollute a lot less than anything else. Add to that the subway and being in walking distance of a lot of things. Compared to, say, bay area suburbanites, new yorkers are absolute angels when it comes to climate change. I guess there are a lot of bay area suburbanites on Slashdot that don't want to hear that.
Having tools so that you could in theory do something is not the same as actually doing them.
Are you telling me that in your programs there are never any variables that are default-constructed, pending later acquisition of the proper value?
If that is so, then you are remarkably... disciplined. Like it or not, you are relying on disciplined developers. But then I knew that as soon as you mentioned "C++".
Your whole point seems to be [...]
No, my whole point is that I believe that a relatively large proportion of the Python bugfixes measured in the article are for bugs that are relatively innocuous. That's all. Then you took the opportunity to attack my competency, because apparently someone can't disagree with you on the internet without being incompetent, but that's your problem, not mine.
If you use boost::optional for every single declaration you make, then you get the same type of runtime errors as in Python. Except with lower quality tracebacks. I expect you don't, and my point stands.
In my line of work, silently computing the wrong value could easily cost my company millions. A minor production stop is manageable, but delivering bad product unnoticed is a disaster. So for me it's a good tradeoff. YMMV.
Statically typed languages often have some sort of default value system, e.g. default-construction in C++. I see that as an unacceptable risk: If I ever try to use the value of a variable that has not been explicitly assigned, then I want an error trap. I do not want the number zero, the empty string or an empty container object to be quietly and misleadingly supplied.
That's what a lot of the AttributeError's in Python are: Indicators of bugs that might have passed silently in a different language. Including some (but not all) statically typed ones.
As for NameError's, that's a tooling issue if you get those.
Re type confusion: yes, that can be annoying, and if you are dealing with undisciplined Python writers who never specify types in interfaces, then I understand how that can be a problem for you.
Python program can be very self-diagnostic. Something goes wrong, it presents as an exception traceback from an uncaught exception.
A lot of bug reports I get go like this: Someone sends me a screenshot with a traceback, I look up the line of the error, find that the error is obvious, fix it, commit the fix, and I still have time for a cup of coffee before 5 minutes have passed. The reporter may not be happy because they can't get on with their work until I cut a new version, but other than that this sort of bug is of very little consequence: no data files have been corrupted or anything like that.
Then there's the other kind of bug, the subtle kind where everything seems to be working fine, but someone checked the output and it just isn't right: the totals on the report don't add up or something. These are the hard ones. And then you have to dig in and hypothesise and experiment and bisect and so on. Of course those bugs happen in Python programs as well.
But I bet the kind of bugs that put Python over average are the first kind, and that Python is below average on the second kind.
Which is a good tradeoff.
Do you know of a competing service with better terms? If you do, then you should let the artists you support know of it, because they're the ones who need to sign up for it and put it on their web page.
Or will you pay $20 for some $10 crap in the artist's store, of which the artist only ever sees $2? That's a horribly inefficient way of supporting artists, but hey, it's great virtue signalling for you, right?
I'm pessimistic about Taler. Quoting from taler.net:
To receive Taler payments, a merchant needs a bank account in the desired currency.
Ever tried opening a bank account in a foreign currency? Ever tried opening 50 of them for 50 different currencies? It's not impossible in the strictest sense of the word, but if you somehow manage it it's going to cost you a small fortune in fees.
And that means Taler will only ever be a system for Americans to receive money from other Americans. I don't even believe the French will use it themselves.
You forgot a factor: The efficiency of converting coal to diesel! For diesel cars, your starting point is diesel. For EV's, your starting point is coal. Why?
More importantly, you forgot cogeneration power plants. Just because a coal power plant is only 40% efficient at creating electricity does not necessarily mean that the rest is lost.
When you're code-generating, why would you care about which warnings are generated? geoskd was talking about writing C source code, and I replied in that vein.
"Developers should avoid writing code by hand and instead write abstract high-level programs that generate code."
"Abstract high-level programs" is code too. Whatever abstraction level you choose to work at, you're still writing code.
C compiler development has a cultural problem: Compiler developers see it as their task to squeeze out every last cycle at any cost, not caring that the result becomes much more fragile. I've always wanted a compiler that tried to diagnose undefined behaviour instead of exploiting it, but noone seems to be selling one.
Lint and similar tools will give you the warning, trivially. There really is nothing in the language that makes issuing that warning hard. It's someone's deliberate choice.
Slashdot Mirror
Don't trust the lighting level info you get from the video. Your eyes are a lot better at dealing withing varying light than a camera. If you had been in the car you would have seen more than you can see on the video.
The video appears to show that only the first 20m in front of the car is illuminated. The next time you drive at night, ask yourself if you can only see 20 meters ahead? I should hope not - probably you can sense movement up to 100 meters or something. I'm guessing it's the same in the Uber car, but the video camera does a bad job of capturing the shadows in the dark.
See, there's the problem: They should have bought regular monitors, not radioactive ones. They tend to decay over time.
3,796,577 square miles to go.
Move somewhere else. The population density of the US is low, low, low. You don't all need to live within 100 miles of one another.
There always was a plethora of compilers on Microsofts operating systems: Watcom, Intel, Borland, Digital Mars, various gcc ports, and many others long forgotten, not to mention Microsoft's offerings.
But these days people seem to have borrowed a notion from Unix: "The platform compiler", and have gotten into their heads that Microsoft(tm) Visual Studio(tm) is just that.
But it isn't! There's no such thing! You just pick whichever compiler you feel feeds the needs of your project. For all the things that suck about Windows development, this is not one of them. There's choice and competition and that is a thing to rejoice about. Do not succumb to the fallacy that because Linux is good, then the cathedral of Linux compiler monoculture is also good.
And yes, I realise that a lot of these compilers also run on Linux, including Clang, which is sort of the point of the article. I'm just ranting because I'm getting sick and tired of OSS projects that on Windows only works with the latest edition of Microsoft(tm) Visual Studio(tm), because that's what the lead developer happens to use, and the lead developer can't be bothered to write portable code, because apparently Windows is such a magical special case that the normal rules of good software development practices don't apply.
End of rant. Diversity good! Monoculture bad! Ugh!
I have mod points, but I couldn't find the "woosh" modifier.
If you say so.
Why on earth would you do that? You have the whole internet at your fingertips, and you pick the slashdot summary as your prime source of information??
There is no world-wide shortage of steel or concrete. We can make as much of that stuff as we need given sufficient energy, and the energy spent on steel and concrete is a tiny fraction of the energy produced. So, not a problem.
That's a cute little bonsai windmill you have there. Just how old is that Morgan Stanley report?
It's hardly a conspiracy theory to note that the Trump administration has opinions on environmental issues.
Tesla was the first modern age mass produced electric car that people thought was cool. Props for that. But they're more than a 100 years too late to lay title to the first mass produced EV. EV's were all the rage 120 years ago.
We can agree that the US as a country is not pushing against EV's. But don't you get the feeling that the US government might be? And in the context of of FAA approvals, the government is a pretty important player.
Another thing about solar power: It's decentralised.
Autocrats like big centralised prestige projects.
If old rappers are ignorant, then they were ignorant when they were young as well. Better to listen to people who keep learning throughout their life.
Worth can mean two things: Market value and value to society.
$14K is the market value. TheReaperD was referring to its value to society.
Except they're not. Per capita, high rise apartment complexes pollute a lot less than anything else. Add to that the subway and being in walking distance of a lot of things. Compared to, say, bay area suburbanites, new yorkers are absolute angels when it comes to climate change. I guess there are a lot of bay area suburbanites on Slashdot that don't want to hear that.
Having tools so that you could in theory do something is not the same as actually doing them.
Are you telling me that in your programs there are never any variables that are default-constructed, pending later acquisition of the proper value?
If that is so, then you are remarkably ... disciplined. Like it or not, you are relying on disciplined developers. But then I knew that as soon as you mentioned "C++".
No, my whole point is that I believe that a relatively large proportion of the Python bugfixes measured in the article are for bugs that are relatively innocuous. That's all. Then you took the opportunity to attack my competency, because apparently someone can't disagree with you on the internet without being incompetent, but that's your problem, not mine.
If you use boost::optional for every single declaration you make, then you get the same type of runtime errors as in Python. Except with lower quality tracebacks. I expect you don't, and my point stands.
In my line of work, silently computing the wrong value could easily cost my company millions. A minor production stop is manageable, but delivering bad product unnoticed is a disaster. So for me it's a good tradeoff. YMMV.
Statically typed languages often have some sort of default value system, e.g. default-construction in C++. I see that as an unacceptable risk: If I ever try to use the value of a variable that has not been explicitly assigned, then I want an error trap. I do not want the number zero, the empty string or an empty container object to be quietly and misleadingly supplied.
That's what a lot of the AttributeError's in Python are: Indicators of bugs that might have passed silently in a different language. Including some (but not all) statically typed ones.
As for NameError's, that's a tooling issue if you get those.
Re type confusion: yes, that can be annoying, and if you are dealing with undisciplined Python writers who never specify types in interfaces, then I understand how that can be a problem for you.
Python program can be very self-diagnostic. Something goes wrong, it presents as an exception traceback from an uncaught exception.
A lot of bug reports I get go like this: Someone sends me a screenshot with a traceback, I look up the line of the error, find that the error is obvious, fix it, commit the fix, and I still have time for a cup of coffee before 5 minutes have passed. The reporter may not be happy because they can't get on with their work until I cut a new version, but other than that this sort of bug is of very little consequence: no data files have been corrupted or anything like that.
Then there's the other kind of bug, the subtle kind where everything seems to be working fine, but someone checked the output and it just isn't right: the totals on the report don't add up or something. These are the hard ones. And then you have to dig in and hypothesise and experiment and bisect and so on. Of course those bugs happen in Python programs as well.
But I bet the kind of bugs that put Python over average are the first kind, and that Python is below average on the second kind. Which is a good tradeoff.
So how are you going to reward artists instead?
Do you know of a competing service with better terms? If you do, then you should let the artists you support know of it, because they're the ones who need to sign up for it and put it on their web page.
Or will you pay $20 for some $10 crap in the artist's store, of which the artist only ever sees $2? That's a horribly inefficient way of supporting artists, but hey, it's great virtue signalling for you, right?
Ever tried opening a bank account in a foreign currency? Ever tried opening 50 of them for 50 different currencies? It's not impossible in the strictest sense of the word, but if you somehow manage it it's going to cost you a small fortune in fees.
And that means Taler will only ever be a system for Americans to receive money from other Americans. I don't even believe the French will use it themselves.
You forgot a factor: The efficiency of converting coal to diesel! For diesel cars, your starting point is diesel. For EV's, your starting point is coal. Why?
More importantly, you forgot cogeneration power plants. Just because a coal power plant is only 40% efficient at creating electricity does not necessarily mean that the rest is lost.
"Abstract high-level programs" is code too. Whatever abstraction level you choose to work at, you're still writing code.
C compiler development has a cultural problem: Compiler developers see it as their task to squeeze out every last cycle at any cost, not caring that the result becomes much more fragile. I've always wanted a compiler that tried to diagnose undefined behaviour instead of exploiting it, but noone seems to be selling one.
Lint and similar tools will give you the warning, trivially. There really is nothing in the language that makes issuing that warning hard. It's someone's deliberate choice.
Data and code pointers are distinct types in C. They are not required to be the same size or convertible to each other.
That gcc doesn't even warn about the conversion is poor quality of implementation. But strictly speaking it's not a C language issue.
Dear automobile industry:
If you're not even using C yourselves, will you stop foisting MISRA on the rest of us.
It's making us misrable.
Kind regards, the people still using C.