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.
it's not the language its systemd thats at fault. systemd is insecure and a poor product.
So ... time to resuscitate Ada?
Positives: there are decades of experience with it.
Negatives: it's not "ooh, shiny!"
Let's write software in some esoteric language that nobody is using. There are less than 10 applications written in it in productive use, and they were all written by the same people who wrote the compiler, but SURELY it will be better than C which is used in everything from your watch to the space probes we send to Jupiter.
You can't fix bad programming by tools. You can only fix bad programming by not hiring bad programmers.
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
The computers they use to run the code are made with politically correct solder instead of lead solder, so the computers are dying faster than the code.
The suggestion to use formal verification has been around for decades. It isn't used outside of the ivory towers because writing a correct specification and proving it's correct is harder than writing correct software. It becomes increasingly difficult as the code base gets bigger and more interfaces are added.
It's like asking if a bad human language are creating bad societies. The answer is of course no.
What a nihilistic article: quote: " it unrealistic to expect programmers to write secure code in memory-unsafe languages." No, its not unrealistic, because it reality disproves the statement. Rock solid things have been built safely in C: most operating systems kernels, modern video editing software, games. Things which need to work directly with the memory like juggling smoothly dozens of gigabytes of video data and fast. not just a smart phone app. Good luck with programming a video editing app in a memory safe language today. Maybe one should pay attention to programmers who have actually created something substantial.
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?
I remember someone proposing my team use ADA to avoid issues with different coding styles because we were bringing together a new team members and they couldn't agree on what C and java should look like...
That person went from hero to zero in a day, though I am certain he is a senior architect now, in fact... sigh.
Also, 20 years of Java have already proven that while putting heavy gloves on a programmer and locking him up in a padded cell may keep him from causing segfaults, it doesn't cause him to know his arse from his elbow.
Let's move towards writing system code in better languages, first of all -- this should improve security and speed.
There ain't no such thing as free memory checking. It takes extra code and therefore takes extra time.
Plus the memory-unsafe premise is BS. There is nothing preventing a programmer from adding their own memory checking in such languages.
And no one will understand it.
The reason unsafe, unmaintainable cruft sticks around is that all these people coming up with new languages don't think to provide a migration path. What's needed:
1. An interface to existing C code, so we don't have to convert all at once. Okay, that one they usually provide. But...
2. Ditto for C++ code.
3. Ditto for Perl 5 code.
4. Tools to assist in translating from old languages to new. Fully automated translation may be over-optimistic, but we can get halfway there.
Or...
1. An improved edition of C/C++ that provides safe pointer features, alternatives to preprocessor, and...
2. DEPRECATES pointer arithmetic and other language malfeatures with obtrusive compile warnings and such.
Then we can get rid of all those compile warnings at our leisure.
If standards bodies don't come through fast enough, let GNU take the initiative.
Bugs in code are not a given, they are only a given for a certain complexity of software created with certain competence with a certain requirement of perfection. The only ways around this is to control the above variables, so this does have some merit. For instance in the process industry when programming safety systems you don't assume perfect competence of the programmer, so you present to them a limited language made of pre-vetted function blocks to limit the amount of damage they can do.
However whenever you limit any damage you likewise limit any usefulness. You can't write all software this way.
Good old BASIC with line numbers and GOTO statements. That's a man's programming language.
This meme, that certain languages are memory unsafe, is BS. The programmer is free to add all the memory checking that a so-called memory safe language automatically inserts. However the programmer using the "unsafe" language is free to use knowledge unavailable to the compiler to decide when and when not to perform such checks.
Furthermore the suggestion that memory-safe languages are faster is bogus. You don't get faster by automatically generating more code.
These memory-safe languages are only more of a necessity for apps written by amateurs. Less of a necessity, and more a convenience, for system software and more important apps written by the knowledgable and experienced.
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).
Most TechCrunch articles are written by complete idiots who know nothing about what they write. Is it just TechCrunch, or is the entire industry at fault?
Got run over by three nekkid guys and shot into pieces.
Next time I become a slave.
"Try Rust! It's safe!" they said.
Well, that is a couple of steps up from bubble wrap and duct tape.
(Although there have been some amazing things done with duct tape.)
But slightly better tools are not the answer.
The problem is the industry attitude that bugs are expected.
'Provably correct' software means you have to write s/w in multiple ways and crosscheck.
Not really a serious alternative for anything except the most basic stuff.
Automatic test tools which slightly munge correct inputs and see what happens seem more likely to be useful.
But again very limited.
Tools that help with the complexity of today's s/w might help a bit.
Automatic garbage collection is a simple start.
Breaking things into small managable pieces (see GO) is only superficially helpful.
It makes it easier to make things with unexpected interactions which are really the bugs to eliminate.
In the 60 and 70's it was a point of pride for the OS team to take an onslaught of eager young CS students and not 'let them in'.
A crash or worse, access, due to anything happening in application space was rare.
S/W is much more complicated now, but this could still be the goal for some basic stuff, like a kernel.
The tool of the time was the assembler.
If you are serious about security, you need simpler s/w and an attitude supporting hackers with bug bounties.
Unfortunately, this is contrary to the business plans of most suppliers.
With a little lobbying, this makes the products and legal system supporting them go in the reverse direction.
Unfortunately, this is a path that violates reality.
It protects us from everybody except the bad guys.
It apparently also supports folks writing articles about how tools will save the day.
NUTS
I remember writing assembly code thinking this is surely to make the program faster than most other code I've written, until I realized the majority of the program was simply making calls into C API's for the most part, defeating the purpose. Until someone writes and operating system in golang I dont think they will really have the security the think they do.
Just because you haven't been hacked yet doesn't mean you are secure
How many products ship with a built in back door with a hard coded password? How many products come with a default administrator account enabled and don't require the user to set a new password? How many products ship with no security at all. Memory safe languages can help prevent one class of bug, but they don't make bad programmers into good programmers.
In fact, the argument could be made that features like memory-safety enable bad programmers to produce bad code that superficially works despite serious design flaws, allowing more bad code to wind up in released products. As long as the finished product superficially works and looks good, it can be sold despite massive defects (just look at the IoT botnet DDOS of Krebs for an example).
Far too many programmers think they are better than they are.
The most commonly used languages do absolutely nothing to prevent programmers from creating completely unmaintainable and broken code. Like creating a public arraylist and then accessing it from all over, or creating 8-layer-deep inheritance hierarchies with untested spaghetti code that's impossible to understand and modify, or copy-pasting all over.
There are efforts to fix some of the problems -- making it harder to use 'null', encouraging immutable objects, simplifying concurrency, more capable type systems, better formal verification and static analysis. Functional languages seem to encourage better practices, although it may be that the self-selection process has led better programmers to adopt these languages. (A good programmer can write solid code even when using shitty tools. It's just more effort.)
In the meantime, if you are a developer: please please please take the time to learn and use good programming practices. SOLID, GRASP, Don't Repeat Yourself, Single Level of Abstraction, intention-revealing names, separation of concerns, input validation. Use TDD and the "red-green-refactor" cycle to minimize technical debt. Use tools that will help you find code smells. Read books like Clean Code, Working Effectively with Legacy Code, Code Complete, The Pragmatic Programmer, Refactoring, and Test Driven Development.
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.
Bashing C/C++ with their ridiculous arguments. If you want to prove your point, go ahead and write software in that kicks the crap out of solutions written in C/C++, or go fuck yourself. We don't care about you trying to be a smartass.
Have fun with rowhammer!
Even hardware enforcement isn't good enough.
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.
Bad languages are creating bad software precisely because too many buggy "me too"-languages are constantly being created to solve problems that don't exist.
Usually, the least buggy implementation of any given software is the C version.
So please stop making shit up to sell your latest langue-du-jour.
The industry as whole would benefit from everyone using standard languages such as C.
And then Intel happened, and we've suffered ever since.
Criticizing C and C++ for being unsafe is quite justified (although both C and C++ can, in fact, be implemented in a type-safe manner). But then lauding language turds like Go and Rust for being safe is laughable. There are plenty of mature safe languages around: Java, C#, Swift, SML, OCaml, Scala, F#; even Python and Clojure are safe (though dynamically typed). In fact, safe languages have been with us for almost as long as there have been programming languages at all, with a long history stretching back to the 1950's: Modula-3, Eiffel, Modula-2, CommonLisp, Ada, Pascal, Algol-68, Algol-60, Lisp, and many others.
Go and Rust were designed by people who are obsessed with problems that used to be issues in the 1980's (concurrency, memory management) but have been largely solved ever since. Go and Rust were obsolete out of the gate, designed by people apparently unwilling to keep up with technology and understand what's going on in the real world.
If you're looking for a safe language, your choice is easy: pick one of Java, C#, or Swift. For really high performance, you can add small, well-tested routines in C.
After a lot of Java, I did a fair chunk of C++11, using all the new features. .cpp files) is awful. I started
Now the features themselves were pretty nice, closures, auto typing, implicit
iteration, but the package structure (.h vs
missing the Ada package structure, believe it or not. One file says
this is what you provide, and the other files provide it, and the compiler
checks it all.
Java has part of this with interfaces, and at least they can be in separate
files, but C++ files are such a mismosh of public and private things. Yes
they're labled "public: and private' but if they're private they shouldn't even
be in the damn public file.
Arrg. A kluge.
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.
The underlying problem is that we write too much code. Each line of code we write has a certain percentage chance of introducing a bug, depending on the language, the developer, the work environment, and so on.
We don't need new languages because they cause the creation of new code and new bugs. The code might have fewer bugs of the sort that the language was designed to eliminate, but we'll still have other bugs. There are always departures from spec.
The solution is to keep debugging one, standard set of libraries so that they are wrung out to the point that there are no deviations from spec. The language doesn't really matter. C would have sufficed. At that point, anyone can plug in those libraries and know precisely-exactly how they'll work. That means that people can invest of themselves in technology that depends on the behavior of those libraries. Graphical tools to visualize the behavior of applications. AI tools to examine and refine designs that use those libraries. And so on.
The authoring of new code - something that software engineers LOVE to do - is the boat anchor holding back the industry.
>hardware array bounds checking
That was implemented in a few processor architectures decades ago. If Intel hasn't implemented it yet it means either it's too complex or too slow. Some hardware engineers that had implemented the aforementioned processor feature ended up in Intel, so I'm pretty sure Intel is aware of such things, including transactional memory, etc.
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
Unless the language in question is PHP, of course.
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.
The original parent post is way off the mark. Natural state of code is feature lacking and buggy. Good code of any decent complexity is always developed and matured over time. Doesn't mean it's impossible to create code that guarantees certain stuff, but you always need to specify what that certain stuff must be, which most people fail miserably at. The more pressure on time, money and work, the worse it gets.
Over time, mature code become bloated, with incoherent bugfixes and featurecreep as well.
You CAN make your own pet project and make it perfect. But it'll be perfect by your standards, and not someone else's. The value will then usually be minimal.
which don't even support strong static typing,
strong static typing is no answer, you are just forcing the programmer to add more code to "get it to compile". look at all the casts in c programs where programmers chafe at static typing.
You can write bad FORTRAN in any language.
Chelloveck
I give up on debugging. From now on, SIGSEGV is a feature.
Just use C, the tools are great and it leaves the programmers in-charge.
This is so funny, thank you /. for my morning jolt!
Strangely enough, a lot of great code was written in C.
Maybe systemd is just a POS, that nobody - except Red Hat - really wanted?
Maybe systemd advocates are just looking for excuses?
Only PHP4 could have allowed WordPress to happen. Only PHP7 could allow it to continue.
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.
And that's the problem. We have to deal with legacy code, written by others.
Reformed C or entirely new language, it costs what it costs regardless.
It's really about priorities. Here in the 21st century, we need safe programs more than we need CPU-efficient programs. I'm not saying performance doesn't matter. I'm saying other things matter more. I don't care how fast your race car runs if it's going to hit a wall.
The best we say can say about unsafe pointer use is that there are special cases where it's worthwhile. It absolutely should not be the default.
C makes it easier to be unsafe than safe. Safe takes extra effort, shooting your users in the foot is enabled. It should be the other way around. Make programmers jump through some hoops to do it the dangerous way, instead of the safe way.
C++ is better, but not all the way there. And there's too much legacy code in C. We need a migration path.
The idea isn't to enable the untalented or unskilled to produce good software. The idea is to put a floor on how bad the bad software can get. Bosses will always hire idiots. Worst case with safe pointers: the idiots fail to produce something that works, so the bosses relent and bring in good programmers. Worst case without: the idiots produce something that seems to work, but then a stray pointer leads to disaster. Which worst case do you prefer?
Also, pointer safe languages take the stress off of good programmers so we can concentrate on the level at which our insight is needed most.
Management sucks. Can we do anything about that? Programmers also suck, because sucky managers hire sucky programmers. Can we do anything about that?
If not, then settle for doing what we can, where we can, to manage and ameliorate the problem we can't fix. It's a Band-Aid, but it's what we have, and better than nothing.
We can't fix human nature. Stupidity is a given. But we can compensate for it.
How would a standard C compiler make use of that when compiling pointer arithmetic? The array bounds are unknown, except just maybe to the programmer.
Get the language semantics right first. That needs doing right now. Then we can optimize the hardware to the semantics at our leisure. Correctness first, speed optimization later.
you could bake the bounds into some pointers at malloc/calloc time. Far from perfect, but an improvement over the status quo.
Anyone remember 286 protected mode?
The standard class library, mainly. They kind of screwed that up, despite several tries. In particular, over-use of exception handling. It's not inherently a bad idea, but they went over the top with it.
I really wanted to love Java. The core language is just fine, I think. Huge improvement there over C and C++. Everything else about it irritates me.
C has been as successful as crack or coca cola.
But in some nations we still have apple juice, yogurt drinks, kwas and 25 other, healthy drinks.
The computer word had memory safe Algol and OSes built on top of that, earlier than Unix. Unisys still sells them. So does fujitsu. HP was selling MPE, programmed in some sort of Pascal very successfully. Customers wanted it. Then the MBAs killed MPE. HP Unix could be crashed by an out of spec ping package, because it is implemented in the C shite.
Just because you were poisoned by Coke and Crack and haven't heard of anything else means zilch.
I like a memory-safe language as much as the next person, but software security really is an open-ended problem. My language may prevent me from making a string that overflows its memory, but if the string I'm building happens to be a SQL query, my code could still to vulnerable to SQL injection. Of course there are several ways to build SQL interfaces which don't allow unchecked strings as queries.
The point is that the SQL injection vulnerability is completely analogous to the string overflow vulnerability. Strings were originally implemented as abstractions in languages which had no concept of "string". There have been many such implementations of strings, and a good fraction of them are not memory safe. But now we also have languages which implement memory-safe strings as an abstraction of the language. And people have used these languages to implement a new abstraction, SQL. Again, there are many implementations. Some are safe from SQL injection. Some are not. The ones which are not safe actually may be simpler to use from a naive point of view - like just building a string and passing it to a function. Some programmers may find that more appealing than an API which requires multiple calls or multiple parameters to make a query. It doesn't require them to learn a new abstraction.
Software security problems will always exist, as long as we continue to build higher-level abstractions with APIs which allow the abstraction to be subverted. Even when you have a safe API to a new abstraction, there's an excellent chance someone will come along an implement a "simpler" API, which is simpler mostly because it is vulnerable.
If the hardware could reliably isolate process memory then such software errors wouldn't lead to security breeches.
At the really low level, what needs to be in the language and what needs to be in the hardware is not set in stone. Microcode is a language, as is the x86-64 ISA and LLVM intermediate code.
Bounds-checking is still a software problem: every array descriptor used by bounds-checking code would still have to be set up by software.
Bounds-checking could (theoretically) be done safely by a compiler of a safe language at some level, if programs were required to go through that compiler.
The problem is that systems today are made for C as the lowest common denominator, and C's programming model is quite permissive.
You can't bounds-check true C in software or in hardware. Doing so and allow pointer arithmetic is hard and you would in effect enforce programs to be in a language that is a subset of C.
Ivan Goddard of Mill Computing has held a few lectures about their novel CPU architecture. In almost every lecture and now and then in the forums he mentions that this or that design detail in the architecture was chosen only so that they could support C's programming model - and that they would have preferred to do it differently.
"We mustn't be caught by surprise by our own advancing technology" -- Aldous Huxley
Creates bad software.
If you think the Symbolics LISP machine ever worked in the real world, you weren't paying attention. Garbage collection, completely top down programming, and the insistence that tail recursion is so cool you *ave* to use it made every program unstable.
We need a feasible plan and tools to convert all that PHP code to something better. Python, maybe.
English is just as much of a cause of certain bugs.
Instead of pushing programmers to a new unknown language every 6 months, which will cause other bugs, why not push to use of code analysis tools?
Granted, C is memory unsafe. But programmers have a good C expertise, and many bugs can be caught automatically.
Writing formal specs, and proving your code meets that formal specs, is very hard, very slow work. Data61 proved that their microkernel implements a formal spec. It took them 25 person-years to implement a 7500 line kernel. Very very few software projects justify that level of expenditure.
I agree that system programming should be moving to languages/environments that make safer programming easier though. Why we're still writing non-performance critical code with buffer overflows in 2016 is beyond me.
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
Well, let's start with one of the real reasons we are in this mess. Programming is not engineering. Let's stop thinking this way.
IIRC IBM S/360 supports separate memory zones in the same program with hardware memory protection. So if you accidentally overwrite something it's restricted to that memory zone.
Some, if not most, of the best software is written in C. A lot of really shitty software is written in supposedly 'safe' nanny languages. A language may hide some of the deficiencies of the programmer and it may even shield the user from a few bugs, but it does nothing to solve the problem.
But seriously, why is fgets still a thing?
C is a language that can lead to insecure programming. So why don't we fix it?
Instead, all that happens is some eliteists claim c is only insecure if you are a ub3r n00b t0 th3 m4x.
In reality, c needs to evolve to make writing applications easier.
Java is probably the nicest form of the C language (language, not runtime, not the standard library).
Java could be improved and solve all of C's problems.
Implement proper memory management for Java. We have new. Let's add free to destroy an object. Make garbage collection optional.
Implement native code generation. Source to byte code to native code.
Rework many of the standard libraries. Make them use free and not rely on gc. And put them all in new packages. Just to spite Larry.
In fact because Larry is such a fucking smelly, grubby, piece of shit, and oracle is just a cunt of an organistion, we probably can't call this language Java or reuse any package names.
Are Flawed Languages Creating Bad Software?
It is always the craftman not the tool. This is not to say there are tools that are more adequate than others. A flaw in the language? A good developer knows how to see shit like that a mile away and work around it (and that has more to do with training and ethics than experience.)
Their article calls for LangSec testing, and applauds the use of languages like Go and Rust over memory-unsafe languages like C.
So what? There is shitty code in Java, C# and even Ruby (which I love but that people treat it as a golden calf.)
The Linux kernel is rock solid, and guess what, it's written in C. It's the developers, always.
Expect to see shitty code in Go and Rust in no time as shitty developers flock to it.
If builders built buildings the way programmers programmed programs, the first woodpecker to come along would destroy civilization.
Certain languages, particularly C and C++ have dangers and pitfalls all over the place. Writing a piece of code that is exception safe or does copy constructors / assignments properly is pain in the ass and unsurprisingly it might not happen properly in a lot of code and lead to leaks / crashes. It's no excuse to blame developers - yes experience will allow some pitfalls to be avoided but the pitfalls often have no reason for being there in the first place.
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.
Hardware is essentially "frozen" software. If you can make perfect hardware, then you can make perfect software. Result:
You can't make a programmer perfect; and by corollary, you can't make an idiot into a programmer.
While I would agree that programmers should have safety related features available to them, shit like Python and JavaScript have gone way out into left field.
I have been trying for 20 years to make a programming language that at least clearly demonstrates the ability of a function to overwrite its boundaries, clearly shows code that will never be hit, etc., but this is extremely hard to do. My imagination is close to sufficient, but not sufficient enough for this task.
Many people have been on the right track with tools such as the venerable flow diagram or UML or even some of the graphical design tools but these are utterly insufficient except to guide the architect. They have no intelligence built in.
Ah well, hopefully someone will come up with a language that is better than C one of these days.
"Someone needs to talk to the tree of liberty about its ghoulish drinking problem." by ohnocitizen
Are you talking about modern extensions of the 360 architecture? The original version had a 24-bit address space that was addressed relative to registers, and no memory safety.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
He is referring to storage protect keys, which were present in the 360 architecture from the start (originally as a feature). For every 2K block of storage there is an associated 4-bit key, and if the 'current' key (in the PSW) does not match the key for the addressed block, a program check interrupt is raised.
I look at programming languages as boxes of tools. C's box includes various drivers and fasteners. C's box also has a blowtorch hot enough to weld steel and a hacksaw sharp enough to cut diamond. I enjoy using this toolbox, as the tools are straightforward, never break, and are capable of creating anything--it just takes a little more time in some cases.
I also enjoy using Python's toolbox. It includes a safety lighter instead of the blowtorch and a CNC machine instead of the hacksaw.
Each set of tools has its place, but if I had to choose one to eliminate from the face of the earth, I would bid farewell to safety lighters and automated machinery--for the same reason I would choose water over tea. Python needs C. Go and Rust need C. We all need C, because things break at every level of the hierarchy.
It was at one time an important milestone in the development of a new language once the language became self-compiling (that is, when you could write the compiler in the language to be compiled; this is known as bootstrapping). This usually necessitated that the initial compiler be written in some lower-level language, but once constructed could be used to re-write the compiler in it's own language, to be compiled and shipped.
But for security reasons, it's unwise to discard the lower-level language implementation. In the article "Reflections on Trusting Trust", Ken Thompson described how a self-replicating trojan might be added to a compiler. But if you have a compiler for your language in some widely implemented lower-level language, there are ways to ensure that the compiler is free of a Thompson trojan.
The first step is to ensure you have a trojan-free compiler for the lower-level language. This can be done through a method that David A. Wheeler called "diverse double-compiling": repeating the bootstrap process on two or more independent implementations of the language and comparing the resulting binaries. For example, compile GCC using Clang, MSVC, and old GCC. This gives you three different GCC binaries, containing different sequences of instructions but ideally with the same behavior. Then compile GCC using each of the resulting GCC binaries. The results should be identical because in the second step, you're compiling GCC with GCC each time. If they differ other than in timestamps, there's a compiler bug, if not a flat-out trojan. If they're the same, then either they're all clean or they all independently implemented the same trojan.
The second step is use a compiler verified as clean through DDC as a stepping stone toward a clean compiler for the target language. For example, you might use old GCC to compile the last version of g++ written in C (before the switch to C++), then use old g++ to compile modern g++. Or you might compile an OCaml compiler written in C, and then use that to compile the old Rust compiler written in OCaml, and finally use that to compile the modern Rust compiler.
But these methods to establish the lack of a Thompson trojan in a compiler will not work if the only publicly available implementation of a language is written in that same language.
Finally, an exception to Betteridge's Law of Headlines.
Its the point where you realize that machine code is too high level that you really realize THAT you are in trouble. The solution (as ever) is Verilog. :D
Below the speed of light Special Relativity is one of the most accurate theories in physics - above the speed of light..
Pascal is now self-hosting in most implementations, although Wikipedia notes that GCC Pascal is an exception, being written entirely in C and not self-hosting, which leads me to assume they don't use DDC at all, and the compiler can't compile itself
If you use a DDC-verified C++ compiler to build any GCC language, such as GNU Pascal, and you've combed the source code of GCC for trojans, then the resulting compiler is by extension DDC-verified because the compilation process's only inputs are GCC's source code and a DDC-verified compiler. The important part with respect to avoiding Thompson trojans is to make sure that there's a chain of implementations in publicly available source code form from a widely implemented language to any given language, even if it does have to pass through (say) old GCC, new GCC, OCaml, old Rust, and new Rust.
Thanks - I completely don't remember that from my 360 assembler days.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes