But PERL is explicitly built on C syntax. QED!
But PERL is explicitly built on C syntax. QED!
"=" 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?
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.
On the other hand, monkeys prefer C, because the programs they generate by jumping on the keyboard have the best chance to compile.
At some point, the developer community will wake up to just how evil C -syntax- is, and how much it has contributed to bugs and security holes.
And all those users who you inconvenienced, or worse, in the middle of the day with an update, loved you for this....
or even "My code is correct, so I don't need to test."
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.
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.
Structural engineers (my father was one) don't have a union and they don't get their degrees from trade schools.
The do have a professional society that is fully engaged in licensing, educational standards for engineering curriculum, and a career path that leads to the necessary experience to qualify for a license, along with testing. They also collaborate with the state Engineering licensing agencies.
On the other hand in computing, at least some of the professional societies have actively argued against licensing. I remember one debate that went something like, "Beauticians are required to have licenses. Should we be like beauticians?" To which the response was, "Doctors have licenses. Should we be like doctors?"
Actually, I have developed software applying DO-178B (although not to Level B/A) for air traffic control, and to Mil-Std 882D for a project that included networked fires and autonomous potentially armed vehicles. On the latter project, I was the lead software safety person for a while.
And to the follow-on comment: Yeah, there's a lot of work to get the hazards and the requirements down to the level that verification against those has real impact. That's part of the job.
and I've been calling for professional licensing and liability for software engineers for at least 30 years. That should follow the approach for other Professional Engineers, including the use of 'engineering practices' as a defense.
The software community has done an appallingly shitty job with software reliability. (Exhibit 1: CERT database of software vulnerabilities.) It's way past time they get held accountable. And yeah, this will slow things down and require people do things right the first time, and it will put a serious dent in the management approach to "throw the cheapest bodies at the software problem, and damn the bugs!" Product liability needs to include both corporate and individual liability.
Email outsourcing companies don't seem to place much value on following rules like SPF and DMARC. A lot of the false positives we get in quarantine are from senders using email outsourcing or "relationship management" companies. After all, the company gets paid by their customer for sending the mail, and has no real accountability whether the customer's email is properly formatted and delivered.
And with large institutions (particularly universities) moving to outsource email and other IT services, this problem will get worse.
(By the way, the same concept applies to phone spam: reliable/unforgeable Caller ID would probably shut most of that down. Of course, that would require the Telephone Companies to make changes. Caller ID should either be 'guaranteed' or the incoming call marked as "no Caller ID" when the caller's phone number can't be verified.)
Well, some research shows you have to download some code, install it on your machine as an RPC server, and then use the command line to get to "LBRY://"
Does this strike anyone else as fraught with IA concerns?
I'm all in favor for open repositories for Creative Commons and Public Domain content, but not if I have to breach my own machine to get to it!
Huh? Not recognized by my browser.
//GO.SYSIN DD *, DOODAH, DOODAH