Introduction

Every man-made thing in the world needs to be designed in order to be built. Of course, DIY projects are often designed as they are built, but other than that, most things are designed before they are built.

And designing a thing is hard.

But as it turns out, designing a thing is easy compared to what I do when I am building a programming language.

At first glance, it seems that designing a programming language is easy; just decide on some easily parsed syntax that sort of conveys what a feature does and call it a day. But that is a shallow view of what I am actually designing.

You see, I am not designing a programming language; I am designing thoughts and a process.

It sounds weird, and perhaps outlandish, but it’s true. Let me explain why.

Notation as a Tool of Thought

Ken Iverson was one of the great pioneers of computer science. He received the Turing Award in 1979 for his work in designing APL, among other things.

His Turing Award lecture was titled “Notation as a Tool of Thought”. It is a long lecture, but the gist of it is captured very well by several quotes at the beginning:

That language is an instrument of human reason, and not merely a medium for the expression of thought, is a truth generally admitted.

— George Bool, Laws of Thought

By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and in effect increases the mental power of the race.

— A. N. Whitehead

The quantity of meaning compressed into small space by algebraic signs, is another circumstance that facilitates the reasonings we are accustomed to carry on by their aid.

— Charles Babbage

In other words, a good notation is a force multiplier for our brains; they increase mental capacity.

However, the converse is also true: poor notation decreases mental capacity.

Dr. Iverson claims, and I agree, that programming languages are a notation and that they can be the best kind of notation. Thus, when designing a programming language, I am not designing a syntax cover for features; I am designing a notation meant as a mental lever.

Good Notation vs Bad Notation

That begs the question: in the context of programming, what makes good notation, and what makes bad notation?

The answer is easy: good notation makes it easy to write good (bug-free) programs, and bad notation makes it hard.

Notations and Programs

Okay, but where do good programs come from? In fact, where do programs come from?

The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination.

— Fred Brooks, The Mythical Man-Month

In other words, programs are thoughts that programmers think.

This all means that good thoughts make good programs, and bad thoughts make bad programs. Thus, a good programming language/notation encourages good thoughts and discourages bad thoughts.

That is why I am trying to design thoughts, albeit indirectly; what I am actually trying to do is to encourage good thoughts and discourage bad thoughts.

And it is not a simple thing to do.

This is why I am not really designing a language, but a process, a process designed to encourage good thoughts and discourage bad ones.

Indirect Design

I hope you now know why my task is so difficult, for designing a process that encourages something indirectly. In fact, it is something that I have not really figured out how to do.

To encourage or discourage something, you design incentives.

There is only one way that I have found that works: I analyze what incentives are produced by particular notations, and when I find an incentive that encourages bad thoughts or discourages good thoughts, I iterate again.

Also, trying to predict what incentives will be produced is exactly the same as trying to guess how people will act in the future: it’s impossible. I mean, I have good ideas of where to start, and I can get somewhat close, but I can’t guarantee that I will be correct.

But maybe I can build Yao to encourage good thoughts.

Good Thoughts

So…what makes good thoughts?

The answer to this question is more subjective, so it is more subject to my tastes and judgment. Whether Yao succeeds or not will mostly depend on whether my tastes and judgment are good or not.

There are a few things I believe are bad that others think are good, such as exceptions. There are other things that I believe are good that others believe are bad.

But regardless of what people think of my judgment, Yao’s success or failure will show whether I am right or not.

Conclusion

I hope you understand better why my job is so difficult. I also hope you understand that I am not just designing a syntax cover over features; I am designing a notation for thought.