Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re:Storage? (Score 1) 478

Well... I'm sure there are some promising technologies, but I'm looking for something that has been -demonstrated- at "city scale" or larger. Answering what "could be" is not the same as answering "here today." (Otherwise, I could make an argument for "clean coal of tomorrow" ;-) )

The problem with dams is that fresh water is an increasingly scarce resource. But there's several thousand years of history using dams and collection ponds to ensure uniform water flows for both consumption and power purposes.

Batteries, particularly those used in electric vehicles, have their own problems such as rare earth production and battery disposal.

I'm definitely not saying "it can't be done", nor am I advocating for coal or fossil fuels in the long run. But I am saying that renewable sources will have significant limits until the storage problem is solved -at scale-.

Comment Re:They both suck! (Score 1) 315

"=" vs "==", the presence or absence of commas or semicolons that substantially change meaning, the mess that is #include in large systems...

Just look at any "obfusticated C" contest entry for egregious examples!

Sure, you can learn and code around them. But at best that's a risk. And we have plenty of examples where those risks have made it to deployed systems. What was the Apple bug on certificates where a semicolon introduced a significant bug in certificate validation that was there for years?

Comment Re:Indeed (Score 3, Informative) 315

And this highlights the difference between C and C++, and better specified/more tightly defined languages.

Two C programmers will ask, "What will this program do?"
Two Ada programmers will ask, "Will this program compile?" Because if it does compile, they both know (and agree on) exactly what the legal program will do.

Comment Re:AI is just software (Score 1) 180

35 years in industry, most of that in "millitary/aerospace" where the consequences are large and often fatal.

Perhaps more importantly, my father, a Structural Engineer with a PE license, and I discussed professional liability many times. He was involved in some court cases as an expert witness when a building fell down. (He said there was blame to go around. Bad design by the architect, incorrect/incomplete specification of materials by the architect and engineer, and the materials that were used failed to meet their own documented capabilities.)

So yes, I think this is not just doable, but also needs to be mandatory, in commercial environments, particularly where the costs of failure are significant (financial and/or human/property damage.) The disclaimer of any warranty, including that the software does what you pay for it, should be made totally illegal.

The core question for the engineering community is whether they get in front of this problem, or they wait for enough catastrophes that the lawyers, courts and particularly the legislatures decide to solve it for us.

Comment Re:AI is just software (Score 1) 180

Well first, the techniques for high confidence software (such as safety-critical) show that -substantial- improvements in software reliability are possible. For commercial avionics, the verification costs are much more (maybe even an order of magnitude) than the development costs. The ROI for verification (such as MCDC) has been questioned (whether the additional surety gained is worth the cost to get it.)

What's most important is the culture of assurance, i.e. 'think before you write', at least anecdotally doing code annotations without associated verification/proof gets you most of the benefits for relatively low costs. (The one thing I liked about Extreme Programming was its emphasis on pair coding and reviews.)

With respect to AI, I think what would work is an axiomatic approach that specifies Must Do/Must Not Do, and verification against those axioms. That's not the same level of verification as line-by-line/instruction-by-instruction avionics code, but it's a heluva lot more than we get now.

Slashdot Top Deals

"No matter where you go, there you are..." -- Buckaroo Banzai