Actually I've dug into it quite a lot since then, and the more I use it the more I'm gravitating away from it. I get it of course. The memory safety is a huge, almost overriding benefit. But I just hope that these ideas get incorporated into a language I like better on the whole.
Explorans limites defectum
I've done a few here on Code Project: [^]
Explorans limites defectum
Some folks might be interest in this... I just posted the code for my CQC home automation system. This is a full on, commercial grade, software based automation system. It's been around for a long time and is very mature. It's built on top of my CIDLib C++ development system, which was open sourced a while back. https://github.com/DeanRoddey/CQC https://github.com/DeanRoddey/CIDLib Between the two of them, that's about 1.1M lines of code covering a very broad range of functionality, all written by me under the influence of massive doses of caffeine. Documentation (from the standpoint of using the system) is here: https://www.charmedquark.com/Web2/CQCDocs/CQCDocs.html?topic=/&page=/Overview Basic build info is on the repository Wiki now. I'll start adding significant info on that front to the above documentation here moving forward. There are lots of videos about CQC here, again from a user point of view: https://www.youtube.com/user/CharmedQuarkSystems/playlists I've done a number of videos about the underlying CIDLib system, which you would want to have an understanding of before working CQC (if you were so interested.) These are from a developer's point of view.: https://www.youtube.com/channel/UCAxCoATHgFBvqZhxFRnZsfw
Explorans limites defectum
I dunno, a new language may engender even more ardent support, because they have an 'us against the world' thing going on or something.
Explorans limites defectum
I just made this post on the Rust section of Reddit and it got removed as offensive or abusive: "The whole variable shadowing thing is just a ridiculously bad idea. I cannot believe that a language so anal retentive about safety would allow such a thing. If there's not an option to have the compiler warning about it, there should be." I mean that's just Rust fan boys suppressing anything that questions the sanctity of Rust.
Explorans limites defectum
C++ has pro level practitioners for sure.
Explorans limites defectum
I definitely don't want to meet them then...
Explorans limites defectum
It's a hard call for me, they both seem so evenly matched.
Explorans limites defectum
You misunderstood. The point was, that it WILL just creep up and creep up and creep up. THEN, when something bad happens (another 911'ish event), suddenly all of these capabilities will lose a large chunk of any controls that might have been put on them, in the name of safety and security. Or, worst case, we have some sort of 70's style social unrest, and it will be completely opened up against the 'trouble makers'. It's always easier for the more paranoid folks who take the 'security at all costs' approach to argue for their way when something goes wrong. The problem is that then these relaxed restrictions seldom get re-tightened after we finish cleaning the fan blades.
Explorans limites defectum
The issue with all of this stuff isn't about now, it's about the future. These types of technologies are going to get better and better, and they'll be incrementally implemented more and more and more over time. Eventually, it's going to get misused and misused badly by someone in power, and of course many, many times over in smaller ways along the way. And there are always people in every country who believe that any measure is justified to achieve whatever goal they have. And that goal may be as laudable as protecting our security. But ultimately the systems they put into place to achieve that goal can become as dangerous as the thing they seek to protect us against when the folks in power start using it against us. The scarier part is when their interest is in protecting themselves. Consider a Nixon administration with the level of surveillance we have now, or what will likely be possible 50 years from now. And by 'us' that means us collectively, or those questioning the government right to do this or that, or those opposing the party in power, or a company or organization that someone is power feels is not in the best interests of the country (which often translates to the interests of their political party or social view or themselves.) And of course it really will hit the fan with something bad happens. Then those folks who have the 'by any means necessary' view of the world are often let off the leash (in a plausible deniability sort of way of course.) And the gains in latitude that they make in those situations are seldom pushed back all the way or even much at all after the crisis is over. Everything is hunky dory until it's not. And ultimately, freedom is not free. That saying often means one particular thing, but it also means that, if you want to be free you cannot be perfectly safe.
Explorans limites defectum
That's only doable on certain types of software. In highly user configurable, very broad software products, there's no practical way to do that. And of course we aren't just talking about refactoring. In many cases it will require jettisoning out of date tools that have deep roots in the code base, and/or rewriting large chunks of it that might contains really complex domain knowledge.
Explorans limites defectum
I think you are simplifying pretty badly there. It doesn't take incompetence or lack of foresight or anything of that nature to get to this situation. It only requires the realities of commercial development where people leave the company and take their knowledge with them, where just keeping up with the competition and customer requirements takes all your time plus some, etc...
Explorans limites defectum
It seems to me that there's a reasonable argument that the thing that creates the most bugs in software is the fear of introducing bugs into the software. The fear is not unreasonable either. If you do semi-major surgery on a large piece of code, almost guaranteed you'll introduce new bugs, and possibly even some big, hairy ones with painful consequences. But, that fear of semi-major (up to major) surgery seems so often to push folks towards always only making incremental and/or localized improvements. And that localized approach also seems to tend to create islands or layers of disparate style and technique and tools. Newer code wants to move forward but can't pull the rest along. Doesn't mean that they are ignoring the cracks in the mortar between the parts, but they just are so loath to pull it all apart and put it back together because of the possible damage. In the end, does that ultimately lead to worse software? I think it does. But of course companies don't sell software in the end, they sell it now and have to deal with the consequences of that. And this is one of those scenarios where there kind of isn't a middle path. The middle kind of becomes the muddle that I describe above, and there's really no moderate way to fundamentally re-tool and you just have to take the pain and get it over with. The optimal thing would be to just start a new code base, taking all the lessons learned and building it right. But that's probably a fool's paradise. It hardly ever would happen that way. The expense and the complexity and teasing all of the intricate details that have been woven into the code and perhaps not really remembered by anyone, etc... Not being able to give up the folks who really understand the current code base, so maybe different folks work on the new one and don't really have that deep understanding of what went wrong the first time, rolling their eyes at the old school crowd and their outdated concerns. And the time scale would likely have to be way too short in order to be commercially viable, so it may end up just being a new and expensive collection of different compromises. Or of course Version 2 Syndrome with a vengeance is a possibility, and it takes twice as long to have enough meetings to decide on further ways to explore possibilities for a deeper understanding of possible modalities for scaling leverage of something or another, than it would have to just have given a small crew of talented people a room and a lot of coffee and left them alone. Maybe in the end, the above doe
So I went back and figured I'd give it another try, just to be fair. I did ultimately find a legitimate though unlikely issue. But, I introduced a bad bug in the process of trying to get rid of warnings, and spent a couple hours trying to figure that out. A lot of the raft of issues it was whining about were just the same ones over and over, because they were in templates and it would spit them out for each use of the offending bit of code. So it was somewhat easier to get rid of them than I thought initially. Though, it's annoying that you don't see the errors until someone uses the code, since it means constantly going back and having to tweak fundamental headers that cause big rebuilds. I have all of these collections set up to pre-instantiate and export for some common element types, but that doesn't seem to enough to make it complain. So it's a bit of a tedious and time consuming process to deal with all of the warning i n those fundamental collection template classes.
Explorans limites defectum
A global suppression of fundamental checks would do no good. Then I would never see any actual legitimate problems of that type, which would make it not worth doing to begin with.
Explorans limites defectum
Ummm... No. I've been a hard core C++ developer for 30+ years and have a 1.1M line personal code base. So it's safe to say I'm not a C style developer. I have my own test framework and my own asserts my own standard library and my own everything, so none of that would be applicable to me. My asserts are appropriately used for things that would represent coding errors, not input errors (obviously no one is 100% consistent in such a large code base.) And of course I can choose to have them on in release if I want, or have separate ones for release vs. debug. GitHub - DeanRoddey/CIDLib: The CIDLib general purpose C++ development environment[^] The issue is writing less readable and maintainable code just to make the analyzer happy. That is likely to cause more problems than the few things it actually manages to catch.
Explorans limites defectum
And, even worse, if you are writing a large, multi-platform system, where different compilers/tools are going to be used, and they will all have their own error/warning codes, it will just be a mess. Creating a macro to hide the suppression mechanism won't help with the error codes. I guess you could say that only one platform will get code analysis but that doesn't seen practical.
Explorans limites defectum
So, since code analysis is included in Visual Studio these days, I figured I'd give it a try. It kicks out endless errors and warngings, every single one of which so far is either wrong or I would have to write far worse code just to make it understandable to the analysis tool in order to make it shut up. The biggest single one so far is that it doesn't recognize that I'm doing a null check or some other check and calling a method that will throw the right exception or that I'm using an assert. I'm not template crazy like most folks these days, but my collections and various other things are templated. I try to keep as much code out of line as possible, and things like throwing exceptions are one of those. But that means it complains about every single place where that happens because it doesn't understand I'm dealing with the problem already. Given that this already causes many hundreds of issues in headers that will be seen basically everywhere directly or indirectly, and I'm not about to hack my code up with hundreds of suppressions before I even really get started, that pretty much makes it useless for me. When you write code to work around lackings in the code analyzer, and make your code more complex and less readable just to make it shut up, that's really letting the tail wag the dog. As I understand it, this is hardly specific to the VS analyzer either.
Explorans limites defectum
Seems like it would be a very unresponsive message pump, given the half second interval between processing events.
Explorans limites defectum
Sadly the world has changed such that you can't make money selling an OS anymore. They may want to do the whole 'join our cloud, or else' thing; but, even if they don't, they have little choice. Blame Google for all of this. When they finally figured out how to get ridiculously rich, without hardly any obligations to anyone for it, and of course by making their users their product, what was the last bird in the coffin under the bridge for companies at that level who actually wanted to sell software products. We are heading straight back to the mainframe and dumb terminal (no matter how pretty the UI is on the terminal now.)
Explorans limites defectum