>The reality is which almost everyone can see is that memory safe languages are pretty much always what you want to be using for new code.
Not everybody is writing security-critical code. For some things productivity and time-to-market is more important and security is not enough of a concern to justify dealing with a language with horrible compile times and a self-righteous, dogmatic community.
> All this complexity is there for a reason — we don’t know how to create a simpler memory safe low-level language. But not every task requires a low-level language to solve it.
And what most people forget is that complexity works against safety: the less the programmer is distracted by other issues (e.g. memory management), the more they can focus on security.
> Problem is readability by maintainers in the future
Sounds like a problem that exists in every single programming language to date. And the reason that problem appears is not because of the languages themselves.
> Is that really a problem on the language's side, though?
Yes, for a language to be good in practice you need to look at what developers actually do and not how a perfectly rational developer would use the language.
> the problem is in fact memory-unsafe languages, and not general engineering practices.
Languages don't introduce bugs by themselves. Engineers produced those bugs.
I always thought that bugs are the programmers' fault, and not to blame the language. It's like blaming the English language because it allows you to misuse it and manufacture very offensive racial slurs, or to be rude and cruel, and thus we should replace it with another language that doesn't allow to exploit these weaknesses. We won't be able to express ourselves with beautifully (low-level) crafted poems anymore, but that's the price to pay.
> programming languages will not be necessary since a big amount of code written in the world is redundant. So minimum declarative stuff will be enough to create the amount of software now built by lot of engineers.
I am not hopeful about that. As a counter example look at parsing. We have studied this for over 50 years. We have really good theory. We even have a good way to do specifications (EBNF). And we even have parser generators such as yacc.
Yet despite this, for reasons of flexibility, performance, and/or good errors, pretty much every production compiler is using a hand written recursive decent parser.
Most problems in computing don’t have nearly the formal theory and study that parsing does. If we can’t make parsing work in the real world, I am not hopeful about the other stuff.
> If the language has the problem that people are fighting with the language in order to become productive with it, perhaps something is wrong with the language, and not the programmers?
Or maybe writing correct (i.e. safe) code is more difficult then most programmers realize and they lack the humility to admit it.
>I think that having a framework written in general purpose language is part of the problem because it allows for things to turn into horrific balls of mud.
Yeah, the problem definitely is that people are able to write code that gets thing done, instead of being unable to perform their work.
> But solving a problem with dynamite is still solving a problem with dynamite; there's a lot more ways it can go wrong than solving the problem with a steam drill, to torture an analogy a bit.
Excepted that a language is not absolute, is not dynamite or not dynamite. It is what you do of it depending of the subset you use. C++ is not exception.
> And today I think we at least need to go to the level of that sub-assembly stuff if one wants to write anything that does not perform badly
You can write fast software today in assembly, C, C++, Rust, and languages like that. You don't need to go to the microcode level. The reason we have trouble with slow, bloated software today is because people don't do that, and instead use slower languages, like Python or JavaScript, using inefficient algorithms, with lots of potentially unnecessary dependencies that optimize for the general case, and not whatever specific problem the programmer wants to solve (which is often less efficient as well).
> Isn’t the issue that most programmers know what to avoid, and yet they make mistakes when writing code anyway.
There's some dose of truth to this, but the statement requires further elaboration to illustrate the complete picture. Programmers understand informally and intuitively what to avoid, yet we make serious mistakes when writing code anyway, because we are all stuck at the prerigorous[0] stage of understanding programming languages. Unfortunately, so long as our languages don't have a formal semantics, there is no way to reach the rigorous stage, let alone the postrigorous stage. (There is no path connecting the prerigorous and postrigorous stages that doesn't pass through the rigorous stage.)
> Seems to me like safe languages is the real solution to this
Safe languages are one solution, perhaps the most useful one in the vast majority of cases. However, legitimate use cases for unsafe languages do exist, and we need workable solutions for those cases. That being said, I don't think an informal English document could be such a solution.
IMHO this only partially true. Think e.g. of memory safety.
reply