Arbor

Philosophy of Arbor

"Brevity is the soul of wit" - William shakespeare

Reading code isn't just about being able to read the code, but also about being able to understand it. This isn't always to do. Providing just enough information to convey your thoughts, with out providing too much information as to overload the reader (often times you) is hard, not only in writting code, but also in writing for humans. After all, Brevity is the soul of wit.

Languages such as C++ and Java are often overly verbose. They overload programmers with extra information and force users to reason about more than just what their code is doing. Take for example this Java Snippet to write to a file:

import java.io.File;
import java.io.IOException;
public class CreateFile {
public static void main(String[] args) {
try {
FileWriter myWriter = new FileWriter("filename.txt");
myWriter.write("Files in Java might be tricky, but it is fun enough!");
myWriter.close();
System.out.println("Successfully wrote to the file.");
} catch (IOException e) {
System.out.println("An error occurred.");
e.printStackTrace();
}
}
}

While its painfully obvious what the code is doing, and what kind of data and objects the code is working with, the keyword is painfully. Often times, a Java project expands into an overly verbose codebase with adapters and factories, and class names that could probably be a program in other languages.

On the other end of the spectrum, we have languages such as Python. For example here is writing to a file in python:

f = open("filename.txt", "w")
f.write("Files in Python might not be tricky, but it is fun enough!")
f.close()

Its much shorter and easier to read than Java. However, in larger codebases, python's conciseness fails to accurately convey critical context. For example if we look at this python function's signature, this lack of context is painfully obvious:

def saveUser(user, db):

What properties are on user? What is the contract of the DB object? Its not easy to tell, and often requires agressive testing in order to make sure everything is being passed around correctly, and when developing code, it requires a lot of back and forth in order for the programmer to figure out exactly what properties are available.

The obvious difference between the Java and Python is the use of types. This seems to introduce a contradiction: types are needed to provide context, but to many types overloads the programmer with types.

Type and type annotation are definitely needed to provide the needed context, but there is a fine line between to much context and not enough, this is a line that Arbor walks.