Slashdot Mirror
Are Flawed Languages Creating Bad Software? (techcrunch.com)
"Most software, even critical system software, is insecure Swiss cheese held together with duct tape, bubble wrap, and bobby pins..." writes TechCrunch. An anonymous reader quotes their article:
Everything is terrible because the fundamental tools we use are, still, so flawed that when used they inevitably craft terrible things... Almost all software has been bug-ridden and insecure for so long that we have grown to think that this is the natural state of code. This learned helplessness is not correct. Everything does not have to be terrible...
Vast experience has shown us that it is unrealistic to expect programmers to write secure code in memory-unsafe languages...as an industry, let's at least set a trajectory. Let's move towards writing system code in better languages, first of all -- this should improve security and speed. Let's move towards formal specifications and verification of mission-critical code.
Their article calls for LangSec testing, and applauds the use of languages like Go and Rust over memory-unsafe languages like C. "Itâ(TM)s not just systemd, not just Linux, not just software; the whole industry is at fault."
Vast experience has shown us that it is unrealistic to expect programmers to write secure code in memory-unsafe languages...as an industry, let's at least set a trajectory. Let's move towards writing system code in better languages, first of all -- this should improve security and speed. Let's move towards formal specifications and verification of mission-critical code.
Their article calls for LangSec testing, and applauds the use of languages like Go and Rust over memory-unsafe languages like C. "Itâ(TM)s not just systemd, not just Linux, not just software; the whole industry is at fault."
It's not the language, it's the programmers and the rush to produce easy code. Speed and simplicity trumps security and efficient coding these days.
Every programming language I have used commercially has had a few things it does well and a whole bunch of limitations. Bad code gets written all the time to work around language limitations. Consider the lack of data type declarations in python, java script, coffeescript, etc. Terrible for code readability.
Its all religious theory and habit with very little up front thought and design. RIP Pascal and Ada.
http://michaelsmith.id.au
Burroughs Large System stack machines were one example and Symbolics Lisp Machines were another. Burroughs had array descriptors that did bounds checking at run time and tagged memory. Tagging added non-user accessible bits to each memory word. The tag defined what kind of data the word contained and the hardware detected any attempt to use a memory value illegally. Symbolics machines also had tag bits, but their implementation was microcoded, so the tag interpretation was also in microcode.
Until computer implementations include features like tagged memory and hardware array bounds checking they will never be truly secure. Some problems cannot be addressed by an isolated software layer: they can only be made secure by hardware enforcement of fundamental features that prohibit some classes of software errors.
Why is Snark Required?
How many rock solid kernels, games or video editing suites are you aware of? I'm aware of zero. Do you not install your updates?
When you write a program that needs to print the primes up to a certain number, you can easily create a formal proof that your program program is correct.
But when your program is say "apache", that needs to interact with many different browsers on one side, and interpret PHP scripts that interact with databases, this formal proof becomes impossible. Similarly, you cannot write a formal spec for the interaction with the user in for example, a web browser.
Even though both examples I put forward today (web server and web browser) didn't exist back then, I've held this opinion for thirty years (spring 1987).
There is nothing preventing a programmer from adding their own memory checking in such languages.
Sure there is: ignorance and laziness.
One of the problems is that programmers generally view PEBKAC as a "get out of jail free" card. Once a problem is diagnosed as PEBKAC, they wash their hands of it and say "not my problem". But ask any UX expert, and they will disagree with this - if a user is having problems with a computer system, it's the computer system's fault (or at least an opportunity for the computer system to be better). Heck, ask any *security* expert about it. You can't just ignore issues because the user did something they shouldn't have -- especially when the line between incompetence and malice is oh so easy to cross.
But guess what: compilers are programs too, and programmers are users of the compilers. Everything about best practices in making interfaces for end user software also applies to the interfaces to programmers' software. And there is no bigger interface to a compiler than the actual language itself.
Let's face it: "you're holding it wrong" is a fucking lousy excuse. Not for one minute would we tolerate a word processing program where the program crashes when you save a file to a USB drive unless you click Edit->Preferences->"Enable USB interface subsystem" first. Or one where saving a file had a 10% chance of failing, and you had to go to About->"Error Messages" to double check whether you saved successfully or you have saved a completely corrupted copy.
While programmers may be smarter than the average bear, that doesn't mean they're smart in an absolute sense. There are plenty of stupid programmers out there, and, sorry to be blunt, Dunning-Kruger means that you're probably one of them.
When you say "memory safe" languages surely you mean managed languages like Java...
Java is of course a completely safe language. There has never been any question about how safe and reliable Java is, and nobody has ever recommended un-installing Java to make your system safer.
"His name was James Damore."
True, but the effort required to do it in (eg.) C is ridiculous. You can't really expect anybody to do it.
Other languages can do it a lot more easily, eg. C++. Range checking for things like std::vector is turned on by default in recent compilers.
ie. "array[-1] = 0x666;" will throw an exception, just like in Java.
You can go outside the box and start using raw pointers in C++ but it's not something you need to do, or should be doing very often.
And *this* is why Linus Torvalds is an idiot with all his anti-C++ rants and "we only use C here" mentality.
No sig today...
Programming languages are just tools to help create programs.
Flawed languages in the hands of skilled programmers can still allow for god programs.
And vice versa.
So my answer is: no, they don't.
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
Posting this issue on /. would never have any meaningful discussion, given the attitude of this crowd towards anything barely resembling formal engineering. When the majority think it's cool to write large and complex systems in languages which don't even support strong static typing, and would have a blank stare if you ask them why they think their code is correct, there is simply no place for any serious discussion. Good tools certainly do not guarantee good outcome, but why do we think bad tools would have good outcome, given the same pool of talents? If we can't fix bad programmers, why not thinking about creating better tools? Formal engineering is hard, and no one said it's easy, but it's not a reason not to strive for better ways.
And then Intel happened, and we've suffered ever since.
New languages and methods always have the advantage over older ones that the big old spaghetti projects written in the newer language with the new method do not exist yet.
The problem is right here:
> opting to cram an enormous amount of unnecessary complexity
Doesn't matter which language is used - as complexity goes up so does the bugginess and new features are increasingly difficult to get working.
This, together with that nobody wants to admit when they think the system becomes too complex, afraid to look stupid.
I think part of it is that software developers simply do not have seas of time to optimize their code to perfection. There's a strong culture of cranking out features as quickly as possible, because otherwise competitors might beat you to the punch.
I think this is a bigger problem than is being recognized here. Most coders that I work with don't get to decide on ship dates. They may in a few cases have a claimed "veto power" if the code isn't ready, but they won't use it, because they'll be let go if they don't ship on time.
The management that I see is too often of the "Give me a demo. What are you talking about, that works fine! Ship it! Let's move the press date up by two months!" variety. Some of the better ones are of the "What's our risk exposure? Hmm... Versus the revenue model... Hmm... It's a close call, but I think the we have to go with the risk to hit our targets" variety. At least they *get* that there is risk.
But the fact is that management and investors don't care if software is buggy and insecure as long as those are "edge cases." They're fully onboard with the Fight Club model. "How many clients will get screwed vs. how much money will we make. Sounds like a good tradeoff."
I think most coders are capable of producing good code in a world in which good code is valued. The problem is that it isn't. Shipping products early and often are the values, and management tends to think that if we can ship code early, do write-offs for the bug and vulnerability cases, and then release the next version before having to patch the one that's about to be shipped, then the entire expense of refining and auditing code can just be eliminated.
At least that's been my experience—the idea is that it's a good way to reduce cost. Release a lot. Be "agile" (hate that word these days), which means: just keep releasing completely new code at an alarming pace. That way, you never have to create good code. You produce a pile of rapidly chucked out, 50% entirely new dogshit every three months with your programmers just barely managing to keep up, you release major versions as fast as you can. Consumers and clients don't get time to be exposed to major bugs and vulnerabilities, or to request that they be fixed, because you release fast enough that your answer can be "That product was released six months ago and is now EOL; no fixes are planned. We recommend that you upgrade to the new version." (The new version also happens to include another revenue item of some kind—upgrade fee, etc.—which is better for the bottom line than providing bug fixes for free.)
I think what we see in software is the same thing we see across the rest of the consumer landscape. Managers and investors have realized that disposable, non-repairable junk is better for the bottom line and for themselves, because it means that consumers have to keep paying over and over again, and often. All of the other employees (e.g. coders) are left to come along for the ride by the seat of their pants, or get fired and replaced by someone who will.
STOP . AMERICA . NOW
And yet, the compiler that Linux uses is now written in... C++ and in the process of converting C style code into C++ style where it makes sense. Because the C code was too unwieldy. Linus wrote his original dive log program in C + GTK, and then was forced to switch to Qt because GTK's attempt at OO made everything unmaintainable.
LLVM and Clang are written in C++ also.
Wrapping things in abstractions is necessary and is done in the Linux kernel all the time with macros, which are less maintainable and more impenetrable than templates. There certainly are things in the kernel that would benefit from being templated rather than macro'd.
Those who do not learn from commit history are doomed to regress it.
First of all it's a programming language not a saw.
Secondly, almost all other languages are compiled using a 'C' compiler.
If the 'C' language were a flawed language then producing code for all those other languages, using 'C' would make all of those languages inherently contain the same systemic flaws.
'C/C++' gets a bad rap from programmers because most programmers lack the skills necessary to make reusable patterns or program securely in any language let alone 'C'.
A better analogy would be that programming has become a lot like carpentry. All manner of people claim to be carpenters and joiners just because they own a hammer. In computing, all manner of people claim to be programmers because they own a computer, have a Comp. 150 or 250 course, became a Microsoft Certified Engineer (what ever that means), or downloaded a free compiler and read a manual once. Such is our culture.
It takes a great deal of experience to understand where problems can be produced in any programming language. Unfortunately the under-informed masses of under skilled programmers tend to be negative about the technologies they understand the least.
The industry needs job entrance tests to demonstrate efficacy in programming rather then simply accepting that people are 'qualified' because they dicked with code for 20 hours in high school.
To a certain extent this can be true. Our society, however, also suffers from anther problem at the other end of this scale.
This is what I refer to as 'Academic Credentialitis'. This disease is pervasive in our society and needs to be stamped out.
There is no certainty that anyone achieving academic standing in any subject actually makes them good enough at that subject to be 'fail-safe' .
There is a systemic myth that somehow links academic standing with actual skill.
Another question is in the context of the design of academic programs. Programs can only be developed reactively based on social context. This means that any new technology that may be disruptive can only have curriculum developed once it is known. If we look at the top 20 historic developments of technology, that have shaped human history in a disruptive way, the majority of those were non-credential-ed developments.
Consider if you will the rise of the desktop computer. It was **NOT** a degreed professional who designed the first broadly successful consumer P.C..
(Wozniak only finished his engineering degree in 1986.) Even If we only consider the commercial success of the PC from an academic perspective, there were no business academics who predicted or persued the development of a consumer personal computer until after it had already arrived on the business scene from a garage. So, in the context of the computing world that we now live in, academia had little to do with the early development and adoption of the PC technology except to claim it after the fact. In short, if we had all adhered to academic credentials as the basis for the development of this technology, none of us would have it right now. We would all still be using tele-type and reading paper newspapers delivered by hand.
The academic myth has been created as a socio-economic filter to ensure that only those with suitable amounts of cash may achieve status in industry or government. This does not scale well to either skill or aptitude.
It has been suggested that aptitude testing would be a better way to validate skill level rather than degrees. The question is, "who designs the test?". There would be a strong bias to load the content of tests with useless information that only a degreed academic would know in just the same way as requests for proposals are biased toward favoured contractors.
The credential is a problem, not a solution. We need to remove our social addiction to that particular social snake oil and get back to skills assessment instead.
Creates bad software.