Syntax on the brain

Lets mash together programming and prose

I am fascinated by programming languages. Not just the ones I interact with to get work done. I have dabbled in quite a few and passively follow the syntax updates of many more.

You may argue that syntax is not nearly as important as semantics, and the whole ecosystem that backs up a language; These are fair observations, but for me , syntax is the smoke that indicates the presence not only of fire, but of what sort of material is burning.

Many languages are designed to solve a specific type of problem, and then as the popularity increases , people who like it, want it to solve more and more problems. The original intentions however, are easily revealed when expressing those first problems syntactically.

I have found that some problems are much easier to understand when presented in a different syntax. I will demonstrate this by imagining the human brain as a computer with very limited working memory trying to parse the meaning of a statement

The following is an extract from Steven Pinker’s The Sense of Style

I have serious doubts that trying to amend the constitution would work on an actual level. On the aspirational level, however a constitutional amendment strategy may be more valuable

When reading this the parser in my mind had to keep the concept of the first sentence attached to the variable actual level, declare the new one aspirational level , and then run a comparison between the two to find out what they have in common and with that deduce whether that commonality is practical , and if it is a valuable aspiration

Out of memory exception?

Pinker also provides an alternative sentence:

I doubt that trying to amend the constitution would actually succeed, but it may be valuable to aspire to it

Here I only need one variable , the concept has already been merged and I easily process whether it is practical and then whether it is a valuable aspiration

It is important to note here that the value is not in the terse nature of the second sentence , but the fact that it has done some of the processing for me saving me valuable memory space to contemplate what all of this means.

You should be able to see from this example that my mind had a much easier time processing the concept of constitutional amendments when the syntax was designed to get that concept across.

Now , Imagine I work backwards. Reading the second passage first gives me an understanding of the first passage instantly. I have a cached set of the results , I know if it’s practical , I know if it’s valuable, and I can now represent this information any way I like ; such as the way it was represented in the first passage.

This logic applies to learning new concepts in programming as well. Let me take the example of the callback. If I were to introduce someone to this concept for the first time, I certainly would not want to show the example in Swift:

Even Atom with the swift language installed doesn’t understand what that thing at the end is

There is a lot to take in here that distracts our learner from what a callback is and what it does, like the way I had to define the function type in the parameter (result: String) -> Void, and the definition of { s in … } as an anonymous function.

However just looking at this solution implemented in javascript tells us exactly what callbacks do:

Here the definition of the anonymous function is almost exactly the same as a standard function definition so we know exactly what it is and what it does just by looking at it. We also do not have a strange typing at the end of callback that looks as though something from lisp was trying to stab something from Visual Basic with a short spear.

Do not mistake this for me saying JavaScript is a good teaching language. I think that is dependant on what you are trying to teach, people can make a horrible mess of JavaScript and while there are a lot of strong opinions on style there is no set standard, this is probably why universities prefer Python, which has its own Zen.

Duck typing has it’s own issues as well , it is terrible when it comes to polymorphism because it offloads the need to remember the interface onto your brain, which as I said earlier, has a limit on the amount of variables it can hold. I would rather have somebody go through the exercise of writing an interface and have them know before they even compile the program that they forgot to implement a method , than experience a runtime error because they had to manually remember every last method they needed to implement.

Different syntax often better represents different problems , and learning a bit of Scala, may help you make better use of those collection methods in C#. A bit of JavaScript , may give you a better understanding of what the hell Alamofire is trying to achieve.

If you had explored other languages , you would have used lambdas before they landed in Java and C#. Map/reduce ? old news. Actors? Those are literally older than I am. Reading the same book twice , may reveal tiny details that you have missed, but new ideas, come from reading something else.