Are Flawed Languages Creating Bad Software? (techcrunch.com) 531
"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."
A poor craftsman blames his tools. (Score:5, Insightful)
Re:A poor craftsman blames his tools. (Score:5, Insightful)
A good craftsman doesn't blame his tools because a good craftsman doesn't use poor tools.
Re: (Score:3, Insightful)
A good craftsman doesn't insist that his tools necessarily do the job for him either.
Re: A poor craftsman blames his tools. (Score:5, Insightful)
Give me a crappy handsaw and nothing else and expect me to do perfectly mitered crown molding in no time at all? You get shit.
Same tools with more time? Now we can talk about my skills I.e. can I do it properly with just that handsaw but time to make it right?
On the other hand, give me a nice table saw where I can simply set the saw to miter correctly and I can do these crown moldings perfectly in no time at all.
The moral of the story? Yes in scenario 2 the poor craftsman will still blame the tools but a good one will also do it because he does know how to do it but he also knows that the table saw exists.
Re:A poor craftsman blames his tools. (Score:5, Insightful)
A good craftsman doesn't insist that his tools necessarily do the job for him either.
As programmers, automation is the essence of what we do. Any programmer who isn't insisting on their tools doing work so they don't have to do it themselves isn't making very good use of those tools. That is as true for safety, security and defensive programming as for any other aspect.
Re:A poor craftsman blames his tools. (Score:5, Insightful)
What happened with "We rely on the developer to do a good job?"
We tried that experiment, and it failed when roughly 0% of professional programmers turned out to be more reliable than an automated tool designed specifically to prevent certain types of programming error.
Can we just stop finding excuses to deliver crap quality code?
You're implying a false dichotomy. There are plenty of programmers who produce generally decent code but still make mistakes that better tools will catch before they go into production.
Re: (Score:2)
>In case of slightest doubts on any of the 2 I go back to the coding table.
That's great if you have unlimited time to work. If you're under extreme pressure to have it working yesterday, and/or are not the one who gets to make the call as to when it's "good enough to ship", then the quality is liable to be much lower.
I think most decent programmers would love to make their code better, but unless they are given the time do do so, they don't have that option. As for you with your unlimited time - if you
Re: (Score:3)
Sure.
Lets ditch double-entry book keeping and make accountants add up properly.
Lets ditch medicines and make doctors heal people with their own skills.
Lets ditch case law and force lawyers to properly argue why their clients are innocent.
Or maybe, just maybe, professional software engineers take full ownership, full responsibility and exploit the tools and systems available to them to maximise the chances of good outcomes without adding unsustainable cost or time burdens on their work.
Maybe.
Re: (Score:3)
Exactly. Trying to treat software development as a true engineering discipline today would be crazy, for the simple reason that we don't know how to reliably do it right yet. There are too many competing theories. There is too little evidence of which are better or worse. A lot of the loudest voices in our industry are not the people producing the best results, because the people who produce the best results are often too busy getting on with it.
Trying to license software developers as a profession too soon
Re: (Score:3)
I am assuming English isn't your first language. I didn't understand a god damn thing you said.
Then you need to work on your own comprehension skills. GP was perfectly understandable in spite of being a bit light in punctuation, using some awkward phrasing, and sporting two minor spelling errors. I've seen *much* worse from so-called 'native' English speakers.
Re: (Score:3)
A programmer that can automate its work will be replaced by his computer in a couple of years tops.
No problem. Once I've finished automating the routine parts of what I currently build, I'll be able to build more capable systems faster next year using the extra time.
Re: (Score:3)
Yes, if you can't function without a point-n'-drool EZ Wizard; you are probably of limited use and facing limited future prospects; but do we seriously expect all those lazy, incomptent, losers who rely on a "file system" to provide a convenient abstraction when a real man could just access the block device directly; or the pansies who use 'compilers' because they suck too much to produce machine code
Re: (Score:3)
Re: (Score:2)
It means that when you eliminate the fancy words, the marketing, the ego, the bullshit and everything else.. programmers automate stuff.
Re: (Score:2)
Thank you. Yes, that's pretty much what I meant.
Re: (Score:3)
Well, I do quite a bit of work in high-performance, high-reliability environments and I've shipped systems that have gone years in production without a single reported implementation bug, so I'll take my chances when it comes to software quality and what good tools can do.
Those results are thanks in no small part to automated methods of catching design and implementation mistakes. I can encode invariants in types. I can write formal specifications and automatically generate large numbers of tests to validat
Re:A poor craftsman blames his tools. (Score:5, Informative)
Re:A poor craftsman blames his tools. (Score:5, Informative)
Yep. Too much 'critical' code is written by the boss's nephew just because he "seems to be good at computers".
Bjarne said it best:
The idea of programming as a semiskilled task, practiced by people with a few months' training, is dangerous. We wouldn't tolerate plumbers or accountants that poorly educated. We don't have as an aim that architecture (of buildings) and engineering (of bridges and trains) should become more accessible to people with progressively less training. Indeed, one serious problem is that currently, too many software developers are undereducated and undertrained. Obviously, we don't want our tools--including our programming languages--to be more complex than necessary. But one aim should be to make tools that will serve skilled professionals--not to lower the level of expressiveness to serve people who can hardly understand the problems, let alone express solutions. We can and do build tools that make simple tasks simple for more people, but let's not let most people loose on the infrastructure of our technical civilization or force the professionals to use only tools designed for amateurs.
- Bjarne
Re: (Score:2)
Or built by some low end contractor who got their degree from a street corner diploma mill school. And then get thrust into building enterprise scale software.
Credential-itis (Score:4, Insightful)
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.
Re: (Score:3)
Definitely agree.
It is really good that programming is so accessible. It was really easy for me to get started back in the day. First in BASIC. Then in C/C++.
The problem is that line between casual use and professional.
I've made bridges before. I built them using Lego at one point. I build them using wood and Popsicle sticks. But who would think that qualifies me to build an actual bridge across a river that people would use?
Or less crazy, I use Excel and know spreadsheets. I have pretty good knowledge of n
Re: (Score:3)
Re: (Score:3, Insightful)
I have worked in the industry since the late 80's. I have NEVER been allowed to choose all of my tools.
Re: (Score:2)
You chose your jobs poorly.
Re: (Score:3)
There we go, blame the victim
False Analogy (Score:4, Insightful)
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.
Re:False Analogy (Score:4, Interesting)
Indeed. And just look at what pretty impressive, secure, stable and fast code is written in C by people that know what they are doing. This whole idiocy about "we need better languages" comes from the same morons that want to teach everybody how to code: They still believe that coding is a menial task that can be done very cheaply, when in actual reality it is among the hardest engineering disciplines known to man.
Re: (Score:2, Interesting)
Re: (Score:3)
If if it crashes
Case in point, semantic analysis is available in some text editors to point out your mistake. A programming language which doesn't require that the programmer state their intentions makes it hard for silly mistakes to be identified early.
Re: (Score:3)
Re:A poor craftsman blames his tools. (Score:5, Insightful)
against what the senior people advice
Most senior people are equally incompetent. Senior programmers tend to be pattern-anti-pattern cargo-cult programmers. They seem competent to those who are incompetent themselves. They also like to use buzzwords. "I'm going to use a no-sql database to increase the scaling performance" only to reinvent a relational database on top of a no-sql database and get strange data oddities because they didn't realize that "transactions" in their chosen no-sql DB does not mean the same thing as "transactions" in a proper relational database. Then after fixing the transnational issues, the no-sql DB is now slower because synchronization is more expensive in no-sql.
Knowledge in an of itself is useless. The Google datacenter is more knowledgeable than any human, yet it is stupid, about as smart as an insect. Wisdom is what one gains from making mistakes, talent allows you to skip making mistakes in the first place. A wise person can correctly recreate what they have already done in the past, talented person can correctly create something entirely new.
Re: (Score:3)
Don't mistake "hipster" for "senior."
The hipsters are the ones braying about NoSQL and the like. The senior engineers are the ones saying, "Yeah, we called those object databases back in the day. Seen it before. It won't solve your problem."
Everything (including so-called NoSQL) has its place. The senior people are the ones who know where that place is, and that nothing is a silver bullet.
Re: (Score:2)
Re:A poor craftsman blames his tools. (Score:5, Insightful)
A good craftsman chooses good tools.
Of course you can create excellent work with very bad tools.
But the first a good craftman does is to search for the right tools. He checks his budget, then starts to search for the right tools and if they are too expensive, he searches for replacements, which are for him (but not for everyone) similiar useful. If he cannot find a tool he needs for good work, he's honest about it and tells his client before starting to work.
Re: (Score:3)
Memory-unsafe is a BS meme (Score:2, Interesting)
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
Re: (Score:3)
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+
Re: (Score:2)
I also understand caution with C++. Its features can be overused to the point of gross inefficiency and/or a lack of clarity in the code. However with highly curated source code like the Linux kernel th
Re: (Score:2)
Re: (Score:3)
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
Re:A poor craftsman blames his tools. (Score:5, Informative)
It's not the language, it's the programmers and the rush to produce easy code.
Well, I think it's a lot the language as well. To a first approximation, every major piece of system and networking software written in C has had serious security issues at one time or another, even the ones written by the best programmers of their generation and hailed as being exemplary in their code quality. I think after the first few decades of evidence we're allowed to call this one now, and say that writing critical software in unnecessarily dangerous languages produces less than optimal results.
Re: (Score:2)
The first time I was confronted with C I was shocked - they check for binary zero as a string terminator? seriously? wtf?
I studied compilers and languages (amongst other things) in the 70's and that one decision - which Dennis Ritchie has since said he very much regrets - flies against everything we were being taught. Of course C had been released a year earlier but I don't remember it being mentioned directly as something to avoid.
What else was there?
Re: (Score:2)
You know well that the same can be said for whatever language you prefer.
Sorry, but I don't agree with that. I see no technical reason why, in 2016, we should still be writing high reliability systems in a programming language with cryptic, error-prone syntax where the default is to accept code that is almost certainly erroneous. Buffer/stack overflows, type mismatches, null pointer errors and numerous other classes of programming bug that are ridiculously common in C code should all have died out years ago, and the reasons for C's continued popularity have very little to do wit
Re: (Score:2)
Re:A poor craftsman blames his tools. (Score:5, Insightful)
I think Bjarne Stroustrup, among others, could reasonably challenge your claim.
But as I said, the reasons for C's continued popularity aren't technical. There's a huge ecosystem around it, including using it as programming's lingua franca. For that to change, either we need an industry heavyweight with enough resources to create not just a better language but the tools and libraries and developer ecosystem around it, or we need some sort of external pressure to drive the change, so that enough professional developers start caring enough about improving quality to switch to new languages and tools despite C's established presence.
Re:A poor craftsman blames his tools. (Score:4, Informative)
C++? It's crap. How many memory allocation methods does it have now? Do you think it makes it easier to debug?
Good luck debugging C++ code heavy with templates and its multi-line warnings/error messages.
C++ is too complicated for little good reason. And complex languages are always harder to debug and more error prone.
Re:A poor craftsman blames his tools. (Score:4, Insightful)
In the application space, you can argue all you want for better languages. There's nothing stopping it there. I'll still disagree with you, but there is no technical reason why the average application can't be written in whatever language you choose. Why? Because the low-level stuff is already done, far beneath your application.
If you're dealing with hardware (eg. writing an operating system, or code for a microcontroller that manages the brakes in your car), then using those higher level languages is a non-start. Every CPU cycle counts, especially in the latter case. Hardware does not understand the high level string constructs (not even C-style NULL terminated ones!) and data structures present in ANY high-level language. Hardware is a collection of registers in specific places that you have to poke and prod in specific orders to make things happen.
Good luck enforcing a safe memory access when that access involves poking raw numbers into sixteen different registers (some bit-level options, some addresses), and then going off to do something else while the DMA hardware (hopefully) executes it the way you intended. At the low level, you're going to be dealing with bounds-unchecked pointers whether you like it or not.
There is none of this safety you want in hardware.
Unless and until someone invents hardware that directly handles "managed code", languages like C are *very* necessary. They are the bridge between the hardware and whatever hipster silver-bullet language you've chosen to solve all your problems today.
Re: (Score:2)
While we have yet to invent a totally foolproof language, there is still a matter of degree. We may never be able to eliminate all programming errors with tools alone, but we can certainly eliminate entire categories of them, and some languages are very much better than others at doing that.
Re: (Score:2)
Exactly this. I am building an application, slowly building it up and taking my time and there are minimal amounts of bugs in it. I test after each section. It's a rebuild of an application I built years ago under extreme time and budget pressure, needless to say the thing is held together with metal wire and duct tape at this point. Now I have the opportunity to rebuild it on my own time frame, it's so much better.
The other problem is that things are trying to be too much. They are following the weirdest c
Re: (Score:3)
Re: (Score:2)
Agile is a manifesto not a process. Part of the manifesto is 'people over process'. Your boss is doing it wrong.
If a prospective employer tells you they are agile the first question should be 'how does your pay compare to local industry averages?' Any answer other than 'our people get substantially above average compensation' tells you they are _not_ agile. Agile emphasises hiring 'competent enthusiastic individuals', those people don't work for industry average (long term).
A person that manages a poor
Re:A poor craftsman blames his tools. (Score:5, Insightful)
Java is a memory safe language. Great error handling too. The language does so many things right, it's scary.
Intermediate result: java attracts incompetent programmers who find that their java code doesn't outright crash the way their C code tends to. Because their code works, more or less, it becomes hard for a non-programmer manager to tell the difference between a java guru and an incompetent boob.
Final result: most java code is utter crap riddled with errors compared to typical C code.
Re: (Score:3)
"A good programmer can write good code in any language, a bad programmer will
Re: (Score:3)
Java has a lot of decent features, but it also made some very bad decisions....sometimes because of premature optimization. E.g., character strings should be either utf-8 or utf-32. Utf-16 was a mistake. My guess is that utf-8 is the best general standard, but there are arguments in favor of utf-32. I know of no valid argument in favor of utf-16.
Also the decision to not compile to native code limited the reasonable domain of use. For many purposes there's no problem with using the jvm, but for others i
Yes (Score:4, Interesting)
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.
Re: (Score:3)
Consider the lack of data type declarations
On the other hand, pretty much every language that uses static typing gives you a way to get around it with overloading, annotations, injections, factories, etc. All of which makes it even more buggy and difficult to read, verify, and maintain.
Re: (Score:2)
Not really. Its a fringe thing now. At a previous place I worked Ada was being auto-translated to java.
Re: (Score:3)
Its actually a good match, you can almost do it with awk. Out parameters and named parameters are two problems I can think of. It does result in a lot of awful java code though,
Who verifies the formal specification? (Score:2)
Re: (Score:2)
There's another problem, writing correct specifications and proving them + code together is correct requires a different set of mental tools. In my estimation, most programmers are terrible at formal logic. It is not computation, it is more like mathematics. Programmers just do not have the mathematical maturity to grind their way thought logical proofs.
And it is extraordinarily time consuming.
Re: (Score:2)
A lot of software isn't critical. Most programmers can do that fine. Things get different when you write the code for autonomous vehicles, space probes or for instance, a dam protecting critical infrastructure. These programs tend to get verified formally because time to market isn't the issue, and the cost of failure is so much greater than the cost of doing it right.
Apart from that: "Anything that makes writing programs harder is absolutely fine with me" - not with me. It needs to be much easier to write
Software isn't enough, hardware must change (Score:5, Interesting)
Burroughs Large System [wikipedia.org] 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.
Re:Software isn't enough, hardware must change (Score:5, Insightful)
And then Intel happened, and we've suffered ever since.
Executes more code but runs faster ? (Score:2)
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.
Re: (Score:2)
The "better" counter to the original argument is that not all bugs are memory overruns.
Back in the early nineties I was reading the manual page for the daemon that would send a message to a terminal when a mail message came in. I concluded, from the "published specs" that I could trick it to do "nasty" things. And that turned out to work.
This is an example where no overrun, just the published actions of a program lead to a security issue.
Re: (Score:2, Interesting)
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 bec
Re: (Score:2)
There ain't no such thing as free memory checking. It takes extra code and therefore takes extra time.
It wasn't clear to me whether the author meant run-time speed or development speed. Certainly better languages and tools can make a big difference to the latter.
It's also quite possible for better languages to generate run-time code that is more efficient. The more semantic information about programmer intent, restrictions and guarantees can be encoded using the language, the more scope there is for optimisers to produce better output.
Plus the memory-unsafe premise is BS. There is nothing preventing a programmer from adding their own memory checking in such languages.
But that only matters if programmers do add their own checks. Evidently i
Re: (Score:2)
But that only matters if programmers do add their own checks. Evidently in reality most do not.
And therefore the idea that the problem is some programmers not the language, the craftsman not the tool.
Re: (Score:2)
If a tool doesn't fit my hand, it's a bad tool. If a tool doesn't fit human intuition and tendencies, it's a bad tool. Tools are here to assist humans, not the other way around, and have no inherent value of their own, just their utility, thus any mismatch between a tool and a user is a problem with the tool,
Re: (Score:2)
Perhaps, but when close to 100% of a population have the same trait, arguments that the trait should be changed rather than designing tools and processes that accommodate that trait are unrealistic and therefore not very useful.
Partially a load of garbage (Score:2)
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 wheneve
Formal verification is worthless IRL. (Score:3)
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).
Re:Formal verification is worthless IRL. (Score:5, Informative)
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.
While things like the halting problem obviously prevent fully formally proving the correctness of programs, you can go much farther than we generally go today. For example, I participated in an EU project [euromils.eu] where they constructed a formal model [isa-afp.org] of the PikeOS separation kernel (kind of like an embedded real-time hypervisor). They also generalised this model, which includes support for things like interrupts and context switches.
Yes, absolutely (Score:2)
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 syste
Re: (Score:2)
Regarding a few of the other comments:
"It is a poor craftsman that blames his tools." Absolutely. However, the same good craftsman who can do amazing things with terrible tools will choose high quality tools because he can do so much better work with them.
"It's... the rush to produce easy code." That continues to be a problem -- and everyone who wants to throw more bodies at a late project needs to be fed a copy of The Mythical Man-Month one page at a time -- but it's a different problem.
"Formal verificatio
Re: The rush to produce easy code. (Score:3)
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
Programmers create bad software (Score:3)
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.
oh boy (Score:3)
ironic (Score:2)
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 langu
Arrogance in the face of complexity (Score:2)
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 loo
Market pressures contribute to the problem (Score:3, Interesting)
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.
Re:what a waste of article (Score:5, Interesting)
Re: (Score:2)
Pretty sure MS-DOS 5.0 was rock-solid enough. It only faltered because things running under it had bugs that overwrote random bits - the kernel itself would be stable.
A non-rock solid game would practically crash frequently. Especially in the early era where patches are unheard-of - if the game is faulty, it's dead.
Most Apogee platformers seemed rather stable. It only took them until RotT before they had a major crash that would lock up a computer.
Re: (Score:2)
if a person or organization doesn't hit the conditions to trigger a bug that causes crash, the OS will appear "rock solid" even if it doesn't to you.
So I admin hundreds of servers, I have my view of what has been "rock solid" though your experience or some study's claims might be different
From my point of view, major linux distros not quite rock solid
AIX, rock solid though a pain to admin
Windows - shaky and unstable
openbsd, rock solid, though you can read their errata list and find fixes for things that wo
Re: (Score:2)
I'm not fooled into believing they actually are rock solid though. The original poster stated that we should look at 'rock solid' things such as kernels, games and video editing suites. They aren't rock solid. They're just predictable, mostly.
Re:what a waste of article (Score:5, Informative)
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.
Re: (Score:2)
In fact, there is no question of how safe and reliable Java is, and nobody that knows what they are taking about has recommended removing Java. The problem with 'Java' is that malicious code can exploit weaknesses in the sandbox (which is not written in Java). The solution is to not run untrusted code, ie disable the browner plugin.
Protection from malicious code is far different than protection from programming bugs that allow inputs to cause malicious operation.
Re: (Score:2)
Well, problems with failing memory checks aside, no language is going to protect against sheer complexity of the result. Given an relatively large program like an OS, C or any other language is not going to stop unanticipated side effects of the many moving parts.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
A rare expression but nothing odd about it. With respect to definition it was correctly used and appropriate for the context.
Rather than showing English is not their native language, it shows a better than average command of the language.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Yeah, the whole "compile-link" thing with separate headers is a bit 1970s.
It does work though and when I look at the sheer number of files/folders languages like Java produce then I'm not sure there's a much better replacement.
Re: (Score:2)
LOL! I've been writing C since the 1980s, pre-ANSI. I've still got my original copy of K&R somewhere.
By modern standards it's a crap language, honestly. I've given up trying to educate C idiots though. They're beyond salvation.
Short version of the final argument:
a) You assert that C is best.
b) I say "Why aren't you writing in assembly language instead of C"?
c) Whatever you reply I simply reword it to replace "Assembler" with "C" and "C" with "C++" then give your own argument back to you.
ie. I use C++ in
Re: (Score:2)
There really should be some form of universal interface that everyone agrees on, rather than trying to create an interface for each individual language. Maybe it could be called an API, and it could accept parameters in an agreed-upon fashion. Perhaps that would solve the interface problem once and for all.
I tried using some of the "safe pointer" stuff - depending on which one is chosen, there is a performance h
Re: (Score:2)
I tried using some of the "safe pointer" stuff - depending on which one is chosen, there is a performance hit depending on which safety mechanism you choose. For example, the auto-deallocate safety net slows things down a lot, while bounds checking tends to be less of a problem.
With shared_ptr, the performance hit is with the reference count updating, so you should still pass a shared_ptr as a reference when possible.
With unique_ptr and the std containers (of movable types), I can't imagine the auto-deallocation would cost any more than manual deallocation in C since they are really just the equivalent of one manual deallocation call.
Re: (Score:2)
Re: (Score:2)
You're saying a good language should include a profiler?