> Therefore, there are ways to write bad code. Do you think it's reasonable there may be better tools that prevent writing some cases of bad code?

Bad code is written every day in every language. The root causes for bad code do not include the chosen programming language. If language was a root cause, every codebase using language <x> would have problem. Clearly that isn't an issue.

Why do we write bad code then?

- Unintended errors
- Bad design
- Not understanding the problem being solved
- Not understanding the constraints
- Not understanding the hardware/environment
- Lack of skill
- Lack of knowledge
- Limited experience with the tools, frameworks, libraries, domain, etc.
- No understanding of lower-level concepts
- Lack of education (formal or self-taught, does not matter)
- Not having a full grasp of fundamentals
- Not being thorough or detail-oriented
- Etc.

There are a lot of reasons for which bad code is written. Language choice isn't one of them. It's an excuse. If baseline languages like C and C++ were so impossible to use properly Linux would be an unmitigated disaster. It is not.

In the end, the language isn't the problem, at all, it's bad software developers.

Don't take my word for it, Linus Torvalds [0] has been quite vocal about this very issue. In fact, he recoils at C++. And, frankly, having seen what comes out of, as he put it, substandard programmers, I could not agree more. I believe part of the problem is how we've been teaching programming. The first thing anyone coming out of school reaches for are complex class hierarchies, complex data types and layers of unnecessary crud.

I remember a project a long time ago that used Objective-C to implemente a genetic solver. It was unusable due to just how slow it was. I re-coded it in C. It ran about 400 times faster on the same iPhone hardware. The first was the result of lazy uninformed programming. The new version was simple, to the point, performant and had no bugs. Not to mention it used massively less memory.

Here's something everyone needs to internalize: The processor --the hardware executing the code-- has no concept of object-oriented anything. No polymorphism, inheritance, complex data types, etc. When all the smoke and bullshit clears out, all it knows is a set of very simple and efficient operations we can weave together to do useful things. That's it.

All the abstractions provided by languages are for the benefit of the programmer and have nothing whatsoever to do with code quality, correctness, bug content or suitability for a purpose. Which means most, if not all of that, isn't necessary.

Modern programmers probably have no clue about the range an scale of projects that were completed without any issues while not having access to things like TDD, objects, massive libraries, complex data types, decorators, etc. I mean, we have written operating systems, sent people to the moon, saved lives with medical equipment, developed consumer and industrial products and more. Funny how all of that was possible and people today go on about needing to use a better language.

In my opinion, there's only one area that can justify a new language. Everything else is well covered with C and, if one must C++. That is, AI. And no modern language fits the bill yet.

It is hard to define what an AI-first language might look like. Being that I used APL professionally for nearly a decade, I happen to think that a language based on a notation developed for AI might be the best idea. The reasons are similar to the reasons for which musical and mathematical notation allow for rich expression of ideas. In other words, the justification isn't "I need it to write better code", but rather that, as the field advances, we might very well need better ways to describe what we want the computer to do.

[0] http://harmful.cat-v.org/software/c++/linus