Introduction
As I said before, I am in the process of designing a programming language (PL). This is the beginning of a series about the principles that I use, as well as the design of the language itself.
Name
The name of the language is Yao.
Cultural Appropriation!!!
No. Just…no.
First off, the same people that say I am bad simply because I am white are the very same people claiming that cultural appropriation exists and that whites are not allowed to “appropriate,” so they are basically saying that I suck and that I am not even allowed to attempt to learn how to not suck.
Second, the Chinese and other cultures seem to like when Americans adopt and appreciate their culture.
Third, culture is meant to be shared, and when we do, we all become better.
Fourth, my wife is half Chinese, and Mandarin was her first language. When we got married, I knew that we would have some Chinese culture in our family. I accepted that and embraced it.
Yào (耀)
Yao, specifically yào (耀), means “shine, illuminate, dazzle” according to Pleco. The church that I am a member of, The Church of Jesus Christ of Latter-day Saints, often uses yào, especially in the scriptures, to denote “glory,” meaning the glory of God.
And that is the reason I named it as I did: if there is anything in it that is good, it is because God has helped me make it so, and I want the world to know that.
However, the name of the language is just “Yao” for simplicity.
Principles
In my last post, I talked about how we, as a software industry, need programming languages that are designed to minimize the cost of development and quality assurance. That is the starting principle behind Yao.
There are only three languages that I know of that are being designed this way: Rust by Mozilla, Jai by Jonathan Blow, and Clojure by Rich Hickey. (Disclaimer: I do not know Jonathan Blow or Rich Hickey personally, though I respect both as programmers.)
Jonathan Blow is first and foremost a game designer and has said that he is not trying to make a language for everyone; he just wants to make one for games. I think that he will succeed because Jai is already the best choice for making games. However, I believe that his focus on games has blinded him to some important constraints that all software, even games, are subject to.
Thus, I would like to go one step farther than he is.
Rich Hickey, on the other hand, is focused on creating a language that minimizes the amount of bugs.
And finally, Rust is focused on making fast and safe software.
I would like to make a language that is good for all software, and like Frederick Taylor, I will do it by focusing on improving the efficiency of process.
Process
It’s important to identify the common elements to all software development methods because otherwise Yao will not be efficient for developing some types of software.
As it turns out, there are many different methods, and they have almost nothing in common. Some are so radically different that, to me, it seems inconceivable that they were conceived and created for the same purpose as others.
But as different as they are, they have one thing in common by definition: they are building, and thus changing, software.
So changing software is the key.
However, that is not all. One methodology, waterfall, is focused on creating software without needing to change it. That seems important.
Now, I’m no expert in economics, but as far as I can tell, the harder that it is to achieve something, the more that must be spent, in time and money, to achieve it. And since the goal of any endeavor is to achieve something at the lowest cost possible, any tool that is employed must be designed to help humans achieve the task as easily as possible.
In the words of Bret Victor, effective tools fit the human and the problem.
So, to make things easy, I have two things I can do:
- Make changes easy to do.
- Reduce the number of changes needed.
Okay, so my purpose is to create an effective tool for programmers. But how? It was kind of hard to figure out until I replaced the word “effective” with the word “optimal” because then it becomes an optimization problem. My purpose now is to (obviously) optimize the tool. That means that I need to maximize or minimize one or more things.
There are two, both of which I am trying to minimize:
- Effort required to make a change.
- Amount of change.
(Yes, this is the same list as above. I wrote it again in the context of the optimization problem.)
Minimize Effort to Make a Change
Here is where Jonathan Blow gets one thing right because he is trying to optimize for one right thing: minimizing “friction.” (He says that he is optimizing for developer happiness and that he does this by reducing friction. I think that reducing friction is the goal, for economic and security reasons, and that developer happiness is a wonderful bonus.) By “friction,” he means the effort required to change software. That sounds like making a tool that makes things easy.
We have a mutual goal then: minimizing friction.
Clojure doesn’t do that; instead, it puts a lot of friction in the developer’s way. This seems like a bad idea, but it does have a good reason for doing so: reducing bugs.
Minimize Change (Bugs)
At this point, a fair question is: why don’t I just go with Jai?
The short answer is that Jai is not designed to minimize the number of required changes. The long answer is useful and not much longer.
Earlier, I said that there might be one or more things that need to be maximized or minimized to make an optimal tool. Jonathan Blow believes that he only has to minimize friction. I disagree.
It is a well-established fact that bugs require changing software, which costs money and time (as well as emotional energy from frustration), to both developers and users. Also, the cost to change the software when bugs are found after release is even higher than finding them during development. Thus, I believe that an optimal PL should be designed to minimize bugs, to reduce the number of changes. Jai is not designed for that; Jonathan Blow has designed Jai to never restrict the programmer, which he believes will improve developer happiness.
In the game world, this makes complete sense because the only way to design a good game is to iterate. A lot. And quickly. And restrictions may reduce the iteration rate.
He may even be right for other software, but I don’t think so; in fact, I think he may be wrong for games too. I think that reducing the bug rate will increase the iteration rate even more than removing restrictions will. Therefore, I think that the language should restrict the programmer from doing obviously stupid things. To be clear, for reasons I explain later, the language will only restrict the programmer, so it will not prevent the programmer from doing anything; it just makes it much harder to do things that have been shown to cause preventable bugs.
So yes, we have a mutual goal. But I have another goal in addition to that one, so Jai will not work for me.
That is why I decided not to go with Jai.
However, Clojure does try to reduce bugs, mostly by memory safety and (basically) pure functional programming. This puts a minor straitjacket on programmers, but as the happy users of Clojure show, the elimination of a lot of bugs can make developers happy.
And happy developers are productive developers. Plus, less bugs mean less cost.
Simplicity
On the other hand, Rust wants to optimize for performance and safety. It has
unsafe, which allows users to break out of the safety and do whatever they
need to.
So why am I not going with Rust either?
Because in order to make it work, Rust is…complicated.
A tool cannot be complicated without putting at risk the usability of that tool. And I do not think Rust is usable.
Conclusion
It is clear that Rust, Jai, and Clojure are not perfect by themselves. Even worse, it is not easy to see how they could be combined in such a way as to keep their advantages and discard their disadvantages.
I think I have a way, but it would take a lot to explain, more than one post, in fact. The next posts will do that.
But since this post is already so long, I will end here.