Memory-safe programming needs a simple language

Rust is the pre-eminent language for memory-safe programming. It also struggles to gain acceptance.

But it's not Rust alone that struggles, it is memory-safe techniques that struggles to gain acceptance. If we work from the assumption that memory-safe programming is a good thing (it is), then we face the question of how to ease the acceptance of memory-safe techniques (and memory-safe programming languages). 

Perhaps we could learn from the history of earlier paradigm shifts in programming languages. The adoption of memory-safe programming techniques strikes me as similar to the adoption of structured programming techniques, and the adoption of object-oriented programming. Structured programming was first implemented in PL/I by IBM, and saw only some acceptance in the IBM community. Object-oriented programming was implemented in Simula (in the 1960s, about the same time as PL/I) but became popular with the Java programming language in the 1990s.

There were several reasons not to use PL/I. It was a large and complex language, and difficult to learn. (This was before the days of internet and web pages, so no online tutorials). It was expensive, as you had to buy the compiler and pay for annual support. (And the executables it produced tended to be large and slow.) The reluctance to use PL/I meant a delay for structured programming.

Structured programming eventually did gain acceptance, though not because of PL/I. It was a different language that people used to learn the techniques of structured programming. That language was Pascal.

Pascal was (and in its original form, still is) a simple language. It was (is) a teaching language, specifically for structured programming. It was developed in an academic environment, not a commercial one. It was readily available for the personal computers of the day, in different implementations. Books were readily available. It was adopted by schools (colleges mostly) as an elective and later a required class.

Pascal in its original form was not suitable for commercial applications. Variants of Pascal were developed that did have features to support large applications; Turbo Pascal and Delphi (an object-oriented variant) were the most well-known. Other languages were developed to handle large, commercial applications and eventually surpassed Pascal in popularity. Yet Pascal was a success because it made people aware and comfortable with structured programming.

Structured programming succeeded because Pascal, a small and limited language was readily available and easy to learn.

Object-oriented programming followed a similar path. The early programming languages were difficult to learn, and not always suitable for large-scale applications. Simula, C++, and Objective-C showed that object-oriented programming was possible, given a large effort over a (relatively) long time.

Object-oriented programming did succeed, and like structured programming, its success was due to a smaller and simpler programming language: Java.

Now let's come back to memory-safe programming.

We can think of Rust as the PL/I of memory-safe programming. Rust demonstrates that it can be done, but it is a large language and learning Rust requires a lot of time and effort.

To follow the paths of structured programming and object-oriented programming, memory-safe programming needs a small, easy-to-learn language. I don't see such a language. Right now, it is either Rust or nothing, and that delays the acceptance of memory-safe programming.

I'm not suggesting that we abandon Rust in favor of a small (and impractical for business) programming language. I'm suggesting that we use a small and simple programming language to teach the concepts of memory-safe programming, and then let people move on to Rust. It is the path that structured programming followed. It is the path that object-oriented programming followed. It seems to work.

The missing conversation about AI

For Artificial Intelligence (AI), -- or at least the latest fad that we call "AI" -- I've seen lots of announcements, lots of articles, lots of discussions, and lots of advertisements. All of them -- and I do mean "all" -- fall into the category of "hype". I have yet to see a serious discussion or article on AI.

Here's why:

In business -- and in almost every organization -- there are four dimensions for serious discussions. Those dimensions are: money, time, risk, and politics. (Politics internal to the organization, or possible with external suppliers or customers; not the national-level politics.)

Businesses don't care if an application is written in Java or C# or Rust. They *do* care that the application is delivered on time, that the development cost was reasonably close to the estimated cost, and that the application runs as expected with no ill effects. Conversations about C++ and Rust are not about the languages but about the risks of applications written in those languages. Converting from C++ to Rust is about the cost of conversion, the time it takes, opportunities lost during the conversion, and reduction of risk due to memory leaks, invalid access, and other exploits. The serious discussion ignores the issues of syntax and IDE support (unless one can tie them to money, time, or risk).

With AI, I have not seen a serious discussion about money, for either the cost to implement AI or the reduction in expenditures, other than speculation. I have not seen anyone list the time it took to implement AI with any degree of success. I have yet to see any articles or discussions about the risks of AI and how AI can provide incorrect information that seems, at first glance, quite reasonable.

These are the conversations about AI that we need to have. Without them, AI is merely a shiny new thing that has no clearly understood benefits and no place in our strategies or tactics. Without them, we do not understand the true costs to implement AI and how to decide when and where to implement it. Without them, we do not understand the risks and how to mitigate them.

The first rule of investment is: If you don't understand an investment instrument, then don't invest in it.

The first rule of business management is: If you don't understand a technology (how it can help you, what it costs, and its risks), then don't implement it. (Other than small, controlled research projects to learn about it.)

It seems to me that we don't understand AI, at least not well enough to use it for serious tasks.