# Building a Language: Math Expressions

If someone tells you to list every math operation you know, you might tell them: addition, subtraction, multiplication and division. And you would be right. Each of these are math operations. But to a programming language, these are the least used math operators in existence.

When a programming language goes to evaluate an expression, it must deal with a variety of math operators. Each of these math operators has a common behavior: it takes 2 values (on the left and on the right) and spits out a single value (the result of the operation).

Basic arithmetic operators all fit this description. And if you were to write a programming language, you could very easily model those operators after this behavior. However, it would be a big waste to forget 3 other operators that have this very same behavior: equals, and, and or.

If you think about the ‘==’ operator (or equality operator), it takes the value on the left and compares it to the one on the right. If both are equal, it outputs a single value: boolean true. The same can be said for ‘and’ and ‘or’. Both look at the values on the left and right of them and output true or false, based on the keyword in use.

If you look at SomeLanguage, you’ll see that all of these math operations are implemented using a single MathOperation behavior that allows expressions to be evaluated very easily.

# The 3 Levels of Thinking

Programmers all over the world start new projects everyday. You can see them start on social sites like Github, or in the shadows of the internet hosted on random servers. Each one of these projects has a purpose and function.

In the recent months, I have come to believe that everything that is done in a project can be talked about in 3 levels of thinking. Furthermore, I believe that these 3 levels of thinking are entirely separate from each other and the way we execute these different types of thinking are very distinct.

The first type of thinking I’d like to propose is Business thinking. This is the type of thinking you would normally credit towards an entrepreneur or inventor. When you are doing business thinking, you are trying to come up with abstract ideas that solve real-world problems. For instance, you might come up with the idea of a keyless lock for your front door, or a Twitter feed that tells you when to water your plant. When you are trying to come up with ideas for a new business venture, you tend to look for problems that need solving.

The funny part about this type of thinking is that it is usually open ended. There seems to be an endless number of ideas that you could implement, as there are. Some people are really bad at this type of thinking because they freeze at the realization of how vast it is and simply can’t hone in on an idea.

The thing about Business thinking is that it can be done by pretty much anyone. Business thinking revolves around how the consumer interacts with a product/service, and doesn’t require a ton of technical knowledge. Because we are all consumers, we can generally grasp the concept of how we want to interact with something. (Not that we are particularly good at it. Many people will say that consumers don’t really know what they want, but I digress.)

The next type of thinking is Functional. Functional thinking start to look at the very abstract parts of the project. It might start to think about how a car has an engine which generates power, and that transfers the power to the drive train and finally to the tires. It might talk about brakes stopping the tires from spinning, a steering wheel turning the wheels, etc. In essence, functional thinking moves away from the base idea of a project and into the actual components that make it work.

This type of thinking is harder than business thinking. It requires more knowledge about the domain, and a general insight to what different mechanisms do. It is much more close ended than business thinking because you are no longer in a giant sea of options. Unlike ideas, which are seemingly infinite, components that preform certain tasks are limited in number. You might have a dozen mechanisms that can stop a wheel from turning, which is a far cry from the number of ideas swirling around in your brain when asked for an idea for a transportation device.

The last part of thinking is Implementation. This is where you separate your entrepreneurs and project managers from your mechanics and programmers. Implementation requires intimate knowledge of how the different parts work, and how to use them properly. A mechanic knows the right bolt, belt, and wrench to use to get a engine up and running. A programmer knows how different objects and protocols and severs communicate with each other to preform the correct actions. Implementation is a highly skilled art.

If you were waiting for the point of all of this paper, you can stop waiting now. I’d like to argue that Implementation is a very closed-mind type of thinking, and that it is this way because of human ability to understand complexity.

It is fairly easy to understand all the details of a program from a Business point of view. You can probably describe a project in a few sentences, or if you really bad, a few paragraphs. Like I said, Business thinking is fairly noncomplex and abstract. Functional thinking is only slightly worse. You could probably explain a developed program in a few pages.

But Implementation is the hard one. Implementation is all the little nuts and bolts that put something together. It is the classes, the interfaces, the constants, variables, functions, all of those things that put together end up making something that works, that is so incredibly complex and low-level that the only way to describe it is by simply looking at it.

But even just looking at the source code can overwhelm someone. It has so many different parts to it, so many different variables and syntaxes and complexities that even most programmers don’t like to think about it.

It is because of these complexities that implementation programming is very closed-minded. Here’s why:

If you’ve looked over how these 3 layers have progressed, you’ll notice when more complexities were added, the number of options were decreased. At the Business level, you have very few complexities so “the sky is the limit”! Any idea could work! You could make rocket! or an airplane! Once you got down into the Functional level, you had more complexities, more things that had to work together, more components you had to think about, and thus you have fewer options. Now you choose between a few dozen wheel sizes and types. But once you get down into the Implementation level, the amount of things affected by any piece of code is so vast that your options are limited to just a few options. For instance, a bolt vs a nail vs a screw. A while vs a for.

And actually, this limitation of ideas isn’t completely factual. It is a human-made reaction to complexity, and you can see it in every profession out there. The more low-level the task, the more likely that someone will have found a solution that works in 98% of cases, and no one will really want to attempt to discover a new methodology. Because the old solution works, they use it. Not only does that person not have to think up a new idea and deal with all the relationships and complexities that a fundamental piece of equipment will have, but they already found a solution, so why bother?

It is because of this human-created reaction, this development of low-level solutions to everyday problems, that low-level thinking is very close-minded. The Implementation view of the world, the extremely low-level view, is not as much of a ‘idea’ creation methodology of thinking, but a methodology of think that takes solutions already created and tries to piece them together into a program that is functional.