Yeap, of course repeat the type of the object twice, the ugly diamond operators, use else if instead of elif, etc, produces verbosity, but this is not related to be easy or not to understand.
The thing is, I think it is related to how easy something is to understand.
If I can express an algorithm as a single function of 10 lines then, other things being equal, that will be easier to understand than distributing the same algorithm across 5 functions each of 20 lines. You can see the whole thing at once, instead of jumping around within or between files. You don't have overheads of passing around and returning values.
Similarly, if I can express a simple bit of logic as a clean one-liner, while a verbose style requires 6 lines of manual loop/conditional logic and maybe a function wrapped around it, then I'm thinking about what that logic is doing and it how it fits in with the other logic around it while you're still worrying about loop counters.
Here's a version of finding all the items less than 10 in a list, written in Haskell, a relatively powerful language:
Here's a slightly more verbose version, written in Python, also a language known for being clean and expressive:
items = [1, 15, 27, 3, 54] result = [item for item in items if item < 10]
And in contrast, here is the best Stack Overflow has to offer about implementing this sort of requirement in Java.
Spoiler: There are basically three kinds of replies. Some write out entire functions to implement the filter using a manual loop. Some use a third party library to do a more clumsy variation of the Python and Haskell examples above. And a few recent ones use Java 8 to do a slightly less clumsy variation of the Python and Haskell examples above. The clear trend is to try to get away from classical, verbose Java to something more powerful and expressive. Like Scala, according to the first comment on the original question...
Generally speaking, the more information you pack into a sequence of characters, the harder it is to understand.
By that argument, doesn't any powerful abstraction make code harder to understand? Similarly, doesn't any verbose style make code easier to understand, even if the boilerplate contributes no additional meaning? Sorry, but I can't agree with this sort of reasoning at all. If it was that simple, we'd still be writing large software systems in assembly language and no-one would use any sort of libraries or modular design.
I'd agree with the ecosystem being a huge factor in Java's success.
More than that, it is a relatively closed ecosystem. Tools like JNI are available, but in practice few projects seem to use them. Mostly, either you're working in JVM world or you're working somewhere else. That's a lot of momentum to overcome for any long-standing project or development team to move to another language, tool chain, standard library, and so on.
I also think the summary's claim that Java is easy for humans to understand at a glance because of its simplicity is a mischaracterisation. Java is a relatively verbose, inexpressive language, so actually it can take quite a long time to figure out how any given piece of code works. What Java does offer is that an average developer can reliably figure out how any given piece of code works, even if it takes a while. For long-running, large-scale projects that is a valuable attribute for a programming language.
I've been programming in Python professionally for something close to a decade now, and in all that time the number of tab/space bugs I've seen in production is: 0.
Get a good edit -- any good editor -- and worry about problems that actually matter. This one was solved in about 1927.
People aren't downloading cracked versions of Donkey Kong. They're downloading cracked versions of the latest Assassin's Creed.
They're doing both.
Most of them aren't.
I agree with you that part of the copyright bargain is (or should be) that works fall into the public domain after a while. You can make reasonable arguments for different periods of protection, but I expect we'd all agree the current ones are absurdly long.
But this doesn't change the fact that most illegal copies being downloaded are relatively new releases.
I agree that some people do download illegal copies for practical reasons rather than cheaping out, though I think this kind of argument is relatively weak. In particular, games companies have actual stats on how many players on their servers are using dodgy copies, and if 90% of the people on their servers are using a version known to be cracked (which is not an unusual figure for some games) then it's hard to believe an argument that all of those people are "just trying it out" and will buy a real copy later, particularly when they are "just trying it out" for two or three months before moving on to whatever is the next popular game.
Your last paragraph is one that troubles me, because it seems to be very common attitude today. In fact, as someone in a new business that creates genuinely original content, I've argued with my government precisely that silly copyright terms erode general respect for copyright, to the point where a lot of people just don't care. This hurts small creative businesses and individual artists who aren't using DRM or otherwise exploiting customers but who also don't have the resources to protect their assets through the legal system.
We just want people using our content to pay a fair price for it so that we in turn can pay our rent at the end of the month. There are many thousands, perhaps even millions, of us for every corporate giant, and copyright is supposed to be there so our business model can work, too. In a world where a lot of consumers don't respect copyright any more, it's mostly not going to be the big businesses that go under; they're just going to push up the cost of next version of GTA or the next season of Game of Thrones by a dollar to compensate. It's the little guys -- the game programming duo slaving away in someone's basement, the individual photographer who travels the world to take beautiful pictures, the recording artists who don't have a big media giant behind them -- who really lose out the most if the system fails.
Anyway, I'd better stop there, because I have to go back to playing my cracked copy of Generic Sports Title 2015 with a bootleg album of Manufactured Pop Band playing in the background, while I download Arbitrary Sci-Fi Reboot Film to watch over dinner. For some reason, no-one seems to make anything good any more, so that's the best I can find.
It is not a black/white issue. If everyone ignored the law and downloaded cracked copies, clearly the games companies would go under as they would have huge costs and no revenue.
Downloading cracked games is like being the guy who drives up the bus-only lane and then cuts in at the junction to get past the queue everyone else is stuck in. You rationalise it with a "victimless crime" mentality, but if you look at the system as a whole, every time someone does that it damages everyone who played by the rules a little bit, and if everyone cheated the whole system would fail.
Those things violate your property rights in about the same way that you having your house violates my right to freedom of movement over the land it's built on.
All property rights are artificial, including physical ones. The natural state of things is that if someone has a bigger stick/rock/gun than you then they can take any physical possession you have if they want to. We create and enforce legal property rights in the hope that they will help society to run better than that. You just seem to want a version of property rights that says you get to have everything you want but everyone else doesn't get anything in return.
This sounds convincing until you realise that the overwhelming majority of content being shared illegally on-line is less than five years old.
People aren't really ripping Star Wars to protest against long copyright periods. They're ripping Age of Ultron so they can watch it for free.
People aren't downloading cracked versions of Donkey Kong. They're downloading cracked versions of the latest Assassin's Creed.
These things would have been illegal under even the earliest and shortest periods of copyright protection. These are titles that took hundreds of people and millions of dollars of investment to make, and the law effectively requiring people to contribute in return for their copy does promote the useful arts by making such projects financially viable.
The trouble with this argument is that even if you are the most well-informed and capable geek on Earth, many of your friends and family won't be. The only way to keep control by your argument is effectively to completely cut yourself off from normal society and live as a hermit.
There is a reason we have laws (and, often, constitutions) protecting basic human rights and freedoms. We also have laws about consumer rights, and data protection, and regulation of critical industries, and fair contract terms. These protections exist precisely because you should not be forced to give up some things just to live a normal life, and no relatively powerful organisation (including, often, your own government) should be able to compel you to do so.
I don't understand the final point you are trying to make, where you talk about being all-in. You certainly can have an underlying capitalist economic model but with regulations or other adjustments on top to create additional incentives. Most first world nations do.
Tracking is not just web 3.0, it's society/globalization 101. One learns to live with it.
Or, like civilised people, we decide that some behaviour is potentially damaging and/or socially unacceptable, we make it illegal, and we punish those who continue to do it.
Also, your continued analogy between what governments do and what private businesses do is silly. Technology is not inherently evil. Storing data about someone is not inherently evil. How you use that technology and what you use that data for may be evil, or may not.
I have the simple option of just not using facebook and get on with my life without it.
No, you don't. That's the point. These organisations built around tracking and data mining are collecting data about you from sources you can't control. Notably, they systematically try to collect information about individuals via for example each individual's friends, without any consent or potentially even knowledge of the data subject.
A feature as simple as having a mobile app that uploads the phonebook to FB gives them a name and number and a link from that shadow account to the phone's owner. All it takes is a few different people installing that app and their mutual friend is associated with all of their accounts, allowing data mining organisations to draw all kinds of probably correct inferences.
And that's just using a single method of data collection via a third party, without any sort of correlation with other data sets, and within a single organisation that at least has a commercial interest in keeping that data very secure and only using it internally. Nothing about your argument guarantees any such favourable conditions, though.
Those are all valid points, and I appreciate that no documentation writers can cover all bases including those reaching beyond their own project. What you can do is be clear about (a) the scope of your particular software, and (b) which protocols/standards/conventions it uses to interoperate with other software. Users don't necessarily need any one project to paint the whole picture for them. It's enough to show that project's particular piece of the jigsaw with a clear enough edge that it fits in with the equivalent documentation from elsewhere.
Exactly. Writing code and writing technical documentation are different skills.
Often different people will have each responsibility, and then identifying and accurately communicating the relevant information between them is a third essential skill.
Strongly disagree, documentation should get straight to the point.
Detailed reference documentation, yes.
But more often than not, the problem with OSS seems to be that no-one wrote the introduction/overview/big picture stuff, and the developers instead expected that users would just magically discover that kind of understanding from 1,943 man pages with cryptic names and no context or navigation to show them where to start.
On a related note, often with OSS there are more than two parties in the conversation.
If I'm configuring some sort of local mail store, I don't just need to know how to set up Dovecot. I need to know how to set up Dovecot, Postfix, Roundcube, and so on, and I need to know how to set them up together.
If I'm configuring some sort of Linux server, I don't just need to know how to set up RAID, I need to know how to do it with logical volumes for future-proofing, and I need to install a bootloader that understands. And then I need status monitoring, and procedures for recovering after failure, adding more capacity, and so on.
Frequently with OSS, particularly sysadmin-type stuff, I find there is more detail than you would likely ever need about any one part of the system, but the real problem is figuring out how to connect it all up in practice.
I agree with you that the C compatibility was a very important factor in C++'s original adoption and success. I also agree with you, at least up to a point, about the value of long-term stability and standards. I don't think C++ should deviate dramatically from its heritage at this point.
Nevertheless, in 2015, things like having a horrible grammar, overcomplicated semantics with numerous edge cases, and such unsafe low-level access are all serious disadvantages for C++ relative to newer languages.
This isn't a criticism of C++ itself or an insult to the people who created one of the most successful programming languages in history. It is simply progress. The constraints of today are not the constraints of the time when C++ was created, and we can do better now.
I think there are several different issues here and perhaps some of our comments are conflating them unfairly.
Certainly we agree that people who just aren't very good at programming will make mistakes in any language.
But I also accept that even people who are quite good at programming are still only human and will inevitably make more subtle mistakes from time to time. The software industry as a whole has an awful track record on quality and performance, and there are whole sub-industries dedicated to tools like debuggers and profilers and static analyzers and refactoring aids because programmers make so many mistakes or poor judgements when left to their own devices. Using better tools can help to catch mistakes and make more informed decisions earlier.
The other major benefit to using those tools is that even if you do have someone outstanding who will code so defensively that there is little that slips through -- as perhaps is the case with the Postfix example -- that always requires a significant amount of effort and compromise -- again as we see with the "safe subset" style of coding used for Postfix. Automating part of the work would have left more time to concentrate on more important and difficult areas like making sure the underlying algorithms are sound in the first place.
Finally, on OpenSSH/OpenSSL, I know the former only depended on the crypto tools rather than libssl, but it seems you are more trusting than me that despite the terrible record of part of the OpenSSL project the risks are confined to just that specific part of it. Presumably then OpenSSH developers themselves consider this a legitimate concern, given the recent moves to separate the projects entirely.
I'm not sure whether this is a deliberate troll, but I'll play along for now just in case you are actually serious.
Comparing problems in languages that allow them with the results in languages where the type system prevents them is entirely fair. These kinds of type systems exist precisely to reliably prevent certain classes of programmer error or otherwise undesirable behaviour in the code from ever compiling.
Yes, there could in theory be a bug in the implementation of such a system, but surely you're not suggesting that the odds of a compiler bug missing such a case due to an error in the implementation of the type system are anywhere close to the odds of a programmer making a similar mistake without the automated tool to help prevent it?
As for "large, security-critical projects done in C", I agree that Postfix has a decent security record, but sadly it's not exactly a representative example. Leaving aside its relatively small size (it's about 100KLOC of C, with much of it written by a single contributor over an extended period), its priority has always been security and it goes to unusual lengths to guard against typical C problems.
For example, the Postfix code includes around 1,000 lines to implement its own custom-written variable-length string tools, which its entire codebase then has to use consistently to remain safe. While the project's respect for security is commendable, in numerous other languages with a built-in string type that effort simply wouldn't have been necessary. So in this case "knowing what you're doing" seems to involve completely discarding large parts of how C is usually written in favour of a home-grown safer alternative that emulates what better languages do as standard. Comparable projects that don't go to such extreme lengths and/or have larger codebases and more functionality, such as Sendmail and Exim, do not enjoy the same kind of track record on security, despite also being widely deployed in security-sensitive environments.
Your OpenSSH example is not so good, because until recently it depended on OpenSSL, which of course has an awful track record for security-related software.
You're absolutely right about inertia in programming ecosystems. There are plenty of fields today that tend to use C++ by default other than games development, simply because there are few if any other mainstream languages that offer the performance, low-level access and native code run-time of C++ without all the downsides.
That doesn't mean we shouldn't try to overcome that inertia, though. C++ has all kinds of legacy baggage from its C heritage that does no-one any favours in 2015, and it lacks numerous modern programming tools that are widely available in other languages. It's underpowered and error-prone.
These things do also matter in the real world. I used to love playing games on my PC, but somewhere in the early 2000s literally every AAA title I spent my hard-earned money on for a couple of years would just keep crashing out. It wasn't the PCs or the graphics drivers or the operating system. It was just crappy programming and management then rushing products out the door. And it spoiled my enjoyment so much that I simply stopped playing those big name titles and never went back.
Of course there will probably always be people who cut corners for commercial reasons, but I don't imagine any of those programmers intentionally dereferenced a null pointer causing the OS to kill their process. It's long past time that even performance-intensive and low-level software was written in languages where that sort of error simply can't happen, and there are easily enough significant applications in the world where these considerations are relevant to achieve critical mass in a new ecosystem. Hopefully Rust will either become a good example of that itself or demonstrate what is possible and lay the groundwork for something else to take over instead.
From read-only/immutability to fine grained ordering, you can specify it all.
That might just about be true with modern C++ standards that actually specify a memory model now. The thing is, even if that is the case, it is true only in the same sense that you can specify whatever behaviour you like in assembly language: while technically correct, it is laborious and error-prone to do so, and there are very much better tools for the job in 2015.
ASM, C, and to some extent C++ have a bad rep because of their lack of training wheels. But in the right hands they are the best and fastest solution to a problem. Plenty of people code, and plenty more people think they can code. Someone who knows what they are doing will not get into trouble in ASM, much less in C or C++.
I contend that the entire history of computing disagrees with you and your hypothetical "person who knows what they are doing" does not exist. If you maintain otherwise, please name a large and widely used program written in any of the above languages that has never encountered the kinds of bug that more sophisticated type systems like Rust's prove can't exist.
Seriously, this article is hosted on a site about a static analyser, whose purpose for existence is to try to identify errors in C and C++ code caused by exactly the kinds of failures you maintain that someone who knows what they are doing won't make. Such tools would be unnecessary if the language design did not admit the possibility of those types of errors in the first place, as is the case with many much safer languages being developed today. This whole piece is basically an attack ad, brought to you by the horse-and-cart drivers who are being made redundant with the invention of the internal combustion engine.
And even if someone, somewhere in the world is smart enough to use a relatively primitive language like C or C++ and not make any mistakes of this kind, that person would surely be orders of magnitude more productive using a modern, expressive, safe language and modern, comprehensive, flexible libraries so they could focus on solving whatever real problem they were dealing with instead of getting bogged down with writing low-level mechanics and defensive programming manually.
Just to be clear, I've nothing against those contracts at all. On the contrary, I think they are the only sensible policy for most drives these days.
I realised that one of my earlier sentences was missing an important comma, but the intended meaning was that any warranty or support contract that only swaps out a failed drive (as distinct from providing a new one but still allowing retention of the failed one) has very limited value to anyone I work with these days. There is just too much risk of data leakage, from commercially sensitive plans (direct economic damage) through personal data (damaging to staff/customers, and regulatory/legal issues for the company) to financial data (potentially very serious regulatory issues).
Personally, I also securely destroy any out-of-use drives I've had in devices at home as well, for similar reasons. The idea that I'd voluntarily send something like a laptop that's had financial records or personal e-mails on it off to some kid at a PC store to swap out a failed drive is just crazy to me.
Slashdot Mirror
Yeap, of course repeat the type of the object twice, the ugly diamond operators, use else if instead of elif, etc, produces verbosity, but this is not related to be easy or not to understand.
The thing is, I think it is related to how easy something is to understand.
If I can express an algorithm as a single function of 10 lines then, other things being equal, that will be easier to understand than distributing the same algorithm across 5 functions each of 20 lines. You can see the whole thing at once, instead of jumping around within or between files. You don't have overheads of passing around and returning values.
Similarly, if I can express a simple bit of logic as a clean one-liner, while a verbose style requires 6 lines of manual loop/conditional logic and maybe a function wrapped around it, then I'm thinking about what that logic is doing and it how it fits in with the other logic around it while you're still worrying about loop counters.
Here's a version of finding all the items less than 10 in a list, written in Haskell, a relatively powerful language:
Here's a slightly more verbose version, written in Python, also a language known for being clean and expressive:
And in contrast, here is the best Stack Overflow has to offer about implementing this sort of requirement in Java.
Spoiler: There are basically three kinds of replies. Some write out entire functions to implement the filter using a manual loop. Some use a third party library to do a more clumsy variation of the Python and Haskell examples above. And a few recent ones use Java 8 to do a slightly less clumsy variation of the Python and Haskell examples above. The clear trend is to try to get away from classical, verbose Java to something more powerful and expressive. Like Scala, according to the first comment on the original question...
Generally speaking, the more information you pack into a sequence of characters, the harder it is to understand.
By that argument, doesn't any powerful abstraction make code harder to understand? Similarly, doesn't any verbose style make code easier to understand, even if the boilerplate contributes no additional meaning? Sorry, but I can't agree with this sort of reasoning at all. If it was that simple, we'd still be writing large software systems in assembly language and no-one would use any sort of libraries or modular design.
I'd agree with the ecosystem being a huge factor in Java's success.
More than that, it is a relatively closed ecosystem. Tools like JNI are available, but in practice few projects seem to use them. Mostly, either you're working in JVM world or you're working somewhere else. That's a lot of momentum to overcome for any long-standing project or development team to move to another language, tool chain, standard library, and so on.
I also think the summary's claim that Java is easy for humans to understand at a glance because of its simplicity is a mischaracterisation. Java is a relatively verbose, inexpressive language, so actually it can take quite a long time to figure out how any given piece of code works. What Java does offer is that an average developer can reliably figure out how any given piece of code works, even if it takes a while. For long-running, large-scale projects that is a valuable attribute for a programming language.
I've been programming in Python professionally for something close to a decade now, and in all that time the number of tab/space bugs I've seen in production is: 0.
Get a good edit -- any good editor -- and worry about problems that actually matter. This one was solved in about 1927.
People aren't downloading cracked versions of Donkey Kong. They're downloading cracked versions of the latest Assassin's Creed.
They're doing both.
Most of them aren't.
I agree with you that part of the copyright bargain is (or should be) that works fall into the public domain after a while. You can make reasonable arguments for different periods of protection, but I expect we'd all agree the current ones are absurdly long.
But this doesn't change the fact that most illegal copies being downloaded are relatively new releases.
I agree that some people do download illegal copies for practical reasons rather than cheaping out, though I think this kind of argument is relatively weak. In particular, games companies have actual stats on how many players on their servers are using dodgy copies, and if 90% of the people on their servers are using a version known to be cracked (which is not an unusual figure for some games) then it's hard to believe an argument that all of those people are "just trying it out" and will buy a real copy later, particularly when they are "just trying it out" for two or three months before moving on to whatever is the next popular game.
Your last paragraph is one that troubles me, because it seems to be very common attitude today. In fact, as someone in a new business that creates genuinely original content, I've argued with my government precisely that silly copyright terms erode general respect for copyright, to the point where a lot of people just don't care. This hurts small creative businesses and individual artists who aren't using DRM or otherwise exploiting customers but who also don't have the resources to protect their assets through the legal system.
We just want people using our content to pay a fair price for it so that we in turn can pay our rent at the end of the month. There are many thousands, perhaps even millions, of us for every corporate giant, and copyright is supposed to be there so our business model can work, too. In a world where a lot of consumers don't respect copyright any more, it's mostly not going to be the big businesses that go under; they're just going to push up the cost of next version of GTA or the next season of Game of Thrones by a dollar to compensate. It's the little guys -- the game programming duo slaving away in someone's basement, the individual photographer who travels the world to take beautiful pictures, the recording artists who don't have a big media giant behind them -- who really lose out the most if the system fails.
Anyway, I'd better stop there, because I have to go back to playing my cracked copy of Generic Sports Title 2015 with a bootleg album of Manufactured Pop Band playing in the background, while I download Arbitrary Sci-Fi Reboot Film to watch over dinner. For some reason, no-one seems to make anything good any more, so that's the best I can find.
It is not a black/white issue. If everyone ignored the law and downloaded cracked copies, clearly the games companies would go under as they would have huge costs and no revenue.
Downloading cracked games is like being the guy who drives up the bus-only lane and then cuts in at the junction to get past the queue everyone else is stuck in. You rationalise it with a "victimless crime" mentality, but if you look at the system as a whole, every time someone does that it damages everyone who played by the rules a little bit, and if everyone cheated the whole system would fail.
Those things violate your property rights in about the same way that you having your house violates my right to freedom of movement over the land it's built on.
All property rights are artificial, including physical ones. The natural state of things is that if someone has a bigger stick/rock/gun than you then they can take any physical possession you have if they want to. We create and enforce legal property rights in the hope that they will help society to run better than that. You just seem to want a version of property rights that says you get to have everything you want but everyone else doesn't get anything in return.
This sounds convincing until you realise that the overwhelming majority of content being shared illegally on-line is less than five years old.
People aren't really ripping Star Wars to protest against long copyright periods. They're ripping Age of Ultron so they can watch it for free.
People aren't downloading cracked versions of Donkey Kong. They're downloading cracked versions of the latest Assassin's Creed.
These things would have been illegal under even the earliest and shortest periods of copyright protection. These are titles that took hundreds of people and millions of dollars of investment to make, and the law effectively requiring people to contribute in return for their copy does promote the useful arts by making such projects financially viable.
The trouble with this argument is that even if you are the most well-informed and capable geek on Earth, many of your friends and family won't be. The only way to keep control by your argument is effectively to completely cut yourself off from normal society and live as a hermit.
There is a reason we have laws (and, often, constitutions) protecting basic human rights and freedoms. We also have laws about consumer rights, and data protection, and regulation of critical industries, and fair contract terms. These protections exist precisely because you should not be forced to give up some things just to live a normal life, and no relatively powerful organisation (including, often, your own government) should be able to compel you to do so.
I don't understand the final point you are trying to make, where you talk about being all-in. You certainly can have an underlying capitalist economic model but with regulations or other adjustments on top to create additional incentives. Most first world nations do.
Tracking is not just web 3.0, it's society/globalization 101. One learns to live with it.
Or, like civilised people, we decide that some behaviour is potentially damaging and/or socially unacceptable, we make it illegal, and we punish those who continue to do it.
Also, your continued analogy between what governments do and what private businesses do is silly. Technology is not inherently evil. Storing data about someone is not inherently evil. How you use that technology and what you use that data for may be evil, or may not.
I have the simple option of just not using facebook and get on with my life without it.
No, you don't. That's the point. These organisations built around tracking and data mining are collecting data about you from sources you can't control. Notably, they systematically try to collect information about individuals via for example each individual's friends, without any consent or potentially even knowledge of the data subject.
A feature as simple as having a mobile app that uploads the phonebook to FB gives them a name and number and a link from that shadow account to the phone's owner. All it takes is a few different people installing that app and their mutual friend is associated with all of their accounts, allowing data mining organisations to draw all kinds of probably correct inferences.
And that's just using a single method of data collection via a third party, without any sort of correlation with other data sets, and within a single organisation that at least has a commercial interest in keeping that data very secure and only using it internally. Nothing about your argument guarantees any such favourable conditions, though.
Those are all valid points, and I appreciate that no documentation writers can cover all bases including those reaching beyond their own project. What you can do is be clear about (a) the scope of your particular software, and (b) which protocols/standards/conventions it uses to interoperate with other software. Users don't necessarily need any one project to paint the whole picture for them. It's enough to show that project's particular piece of the jigsaw with a clear enough edge that it fits in with the equivalent documentation from elsewhere.
Exactly. Writing code and writing technical documentation are different skills.
Often different people will have each responsibility, and then identifying and accurately communicating the relevant information between them is a third essential skill.
Strongly disagree, documentation should get straight to the point.
Detailed reference documentation, yes.
But more often than not, the problem with OSS seems to be that no-one wrote the introduction/overview/big picture stuff, and the developers instead expected that users would just magically discover that kind of understanding from 1,943 man pages with cryptic names and no context or navigation to show them where to start.
Make it conversational as well as informative.
On a related note, often with OSS there are more than two parties in the conversation.
If I'm configuring some sort of local mail store, I don't just need to know how to set up Dovecot. I need to know how to set up Dovecot, Postfix, Roundcube, and so on, and I need to know how to set them up together.
If I'm configuring some sort of Linux server, I don't just need to know how to set up RAID, I need to know how to do it with logical volumes for future-proofing, and I need to install a bootloader that understands. And then I need status monitoring, and procedures for recovering after failure, adding more capacity, and so on.
Frequently with OSS, particularly sysadmin-type stuff, I find there is more detail than you would likely ever need about any one part of the system, but the real problem is figuring out how to connect it all up in practice.
I agree with you that the C compatibility was a very important factor in C++'s original adoption and success. I also agree with you, at least up to a point, about the value of long-term stability and standards. I don't think C++ should deviate dramatically from its heritage at this point.
Nevertheless, in 2015, things like having a horrible grammar, overcomplicated semantics with numerous edge cases, and such unsafe low-level access are all serious disadvantages for C++ relative to newer languages.
This isn't a criticism of C++ itself or an insult to the people who created one of the most successful programming languages in history. It is simply progress. The constraints of today are not the constraints of the time when C++ was created, and we can do better now.
I think there are several different issues here and perhaps some of our comments are conflating them unfairly.
Certainly we agree that people who just aren't very good at programming will make mistakes in any language.
But I also accept that even people who are quite good at programming are still only human and will inevitably make more subtle mistakes from time to time. The software industry as a whole has an awful track record on quality and performance, and there are whole sub-industries dedicated to tools like debuggers and profilers and static analyzers and refactoring aids because programmers make so many mistakes or poor judgements when left to their own devices. Using better tools can help to catch mistakes and make more informed decisions earlier.
The other major benefit to using those tools is that even if you do have someone outstanding who will code so defensively that there is little that slips through -- as perhaps is the case with the Postfix example -- that always requires a significant amount of effort and compromise -- again as we see with the "safe subset" style of coding used for Postfix. Automating part of the work would have left more time to concentrate on more important and difficult areas like making sure the underlying algorithms are sound in the first place.
Finally, on OpenSSH/OpenSSL, I know the former only depended on the crypto tools rather than libssl, but it seems you are more trusting than me that despite the terrible record of part of the OpenSSL project the risks are confined to just that specific part of it. Presumably then OpenSSH developers themselves consider this a legitimate concern, given the recent moves to separate the projects entirely.
I'm not sure whether this is a deliberate troll, but I'll play along for now just in case you are actually serious.
Comparing problems in languages that allow them with the results in languages where the type system prevents them is entirely fair. These kinds of type systems exist precisely to reliably prevent certain classes of programmer error or otherwise undesirable behaviour in the code from ever compiling.
Yes, there could in theory be a bug in the implementation of such a system, but surely you're not suggesting that the odds of a compiler bug missing such a case due to an error in the implementation of the type system are anywhere close to the odds of a programmer making a similar mistake without the automated tool to help prevent it?
As for "large, security-critical projects done in C", I agree that Postfix has a decent security record, but sadly it's not exactly a representative example. Leaving aside its relatively small size (it's about 100KLOC of C, with much of it written by a single contributor over an extended period), its priority has always been security and it goes to unusual lengths to guard against typical C problems.
For example, the Postfix code includes around 1,000 lines to implement its own custom-written variable-length string tools, which its entire codebase then has to use consistently to remain safe. While the project's respect for security is commendable, in numerous other languages with a built-in string type that effort simply wouldn't have been necessary. So in this case "knowing what you're doing" seems to involve completely discarding large parts of how C is usually written in favour of a home-grown safer alternative that emulates what better languages do as standard. Comparable projects that don't go to such extreme lengths and/or have larger codebases and more functionality, such as Sendmail and Exim, do not enjoy the same kind of track record on security, despite also being widely deployed in security-sensitive environments.
Your OpenSSH example is not so good, because until recently it depended on OpenSSL, which of course has an awful track record for security-related software.
You're absolutely right about inertia in programming ecosystems. There are plenty of fields today that tend to use C++ by default other than games development, simply because there are few if any other mainstream languages that offer the performance, low-level access and native code run-time of C++ without all the downsides.
That doesn't mean we shouldn't try to overcome that inertia, though. C++ has all kinds of legacy baggage from its C heritage that does no-one any favours in 2015, and it lacks numerous modern programming tools that are widely available in other languages. It's underpowered and error-prone.
These things do also matter in the real world. I used to love playing games on my PC, but somewhere in the early 2000s literally every AAA title I spent my hard-earned money on for a couple of years would just keep crashing out. It wasn't the PCs or the graphics drivers or the operating system. It was just crappy programming and management then rushing products out the door. And it spoiled my enjoyment so much that I simply stopped playing those big name titles and never went back.
Of course there will probably always be people who cut corners for commercial reasons, but I don't imagine any of those programmers intentionally dereferenced a null pointer causing the OS to kill their process. It's long past time that even performance-intensive and low-level software was written in languages where that sort of error simply can't happen, and there are easily enough significant applications in the world where these considerations are relevant to achieve critical mass in a new ecosystem. Hopefully Rust will either become a good example of that itself or demonstrate what is possible and lay the groundwork for something else to take over instead.
From read-only/immutability to fine grained ordering, you can specify it all.
That might just about be true with modern C++ standards that actually specify a memory model now. The thing is, even if that is the case, it is true only in the same sense that you can specify whatever behaviour you like in assembly language: while technically correct, it is laborious and error-prone to do so, and there are very much better tools for the job in 2015.
ASM, C, and to some extent C++ have a bad rep because of their lack of training wheels. But in the right hands they are the best and fastest solution to a problem. Plenty of people code, and plenty more people think they can code. Someone who knows what they are doing will not get into trouble in ASM, much less in C or C++.
I contend that the entire history of computing disagrees with you and your hypothetical "person who knows what they are doing" does not exist. If you maintain otherwise, please name a large and widely used program written in any of the above languages that has never encountered the kinds of bug that more sophisticated type systems like Rust's prove can't exist.
Seriously, this article is hosted on a site about a static analyser, whose purpose for existence is to try to identify errors in C and C++ code caused by exactly the kinds of failures you maintain that someone who knows what they are doing won't make. Such tools would be unnecessary if the language design did not admit the possibility of those types of errors in the first place, as is the case with many much safer languages being developed today. This whole piece is basically an attack ad, brought to you by the horse-and-cart drivers who are being made redundant with the invention of the internal combustion engine.
And even if someone, somewhere in the world is smart enough to use a relatively primitive language like C or C++ and not make any mistakes of this kind, that person would surely be orders of magnitude more productive using a modern, expressive, safe language and modern, comprehensive, flexible libraries so they could focus on solving whatever real problem they were dealing with instead of getting bogged down with writing low-level mechanics and defensive programming manually.
Just to be clear, I've nothing against those contracts at all. On the contrary, I think they are the only sensible policy for most drives these days.
I realised that one of my earlier sentences was missing an important comma, but the intended meaning was that any warranty or support contract that only swaps out a failed drive (as distinct from providing a new one but still allowing retention of the failed one) has very limited value to anyone I work with these days. There is just too much risk of data leakage, from commercially sensitive plans (direct economic damage) through personal data (damaging to staff/customers, and regulatory/legal issues for the company) to financial data (potentially very serious regulatory issues).
Personally, I also securely destroy any out-of-use drives I've had in devices at home as well, for similar reasons. The idea that I'd voluntarily send something like a laptop that's had financial records or personal e-mails on it off to some kid at a PC store to swap out a failed drive is just crazy to me.
TFA says that, but I didn't see anything in the primary source (the formal legal paperwork) to support it.
The relevant phrasing direct from the complaint says things like:
In April 2014, Intermex asked Plaintiff and other employees to download an application ("app") called Xora to their smart phones.
Yes, I do. Did you actually read my post to the end before replying?