# Fun with Spheres pt 2

My previous explorations really taught me that I had absolutely NO CLUE how to spherical geometry, so I’ve spent these past weeks teaching myself how to get around in spherical coordinates. I’ve  come up with a potpourri of sketches exploring spherical geometry. These are mostly for my own benefit, but I thought I’d share anyways.

This sketch does the simplest things, like drawing great circles and small circles. It was a very good primer to start thinking in a spherical mindset. The strategy at this point was to always imagine important vectors being aligned along the XYZ axes, and which reduced the problem down to a much simpler one, and then implementing the solution through rotation transformations.

I wondered what kind of path a point on the sphere would take if it was constantly rotating around some moving axis. To this end, Rodrigues’ rotation formula proves extremely helpful.

Going back to my roots – gravitation! The red ball is gravitationally attracted to the green balls using a spherical distance metric. This was actually tricky because velocities aren’t as straightforward as they are in Euclidean space. I ended up creating the notion of a “Local Plane”, which is basically an azimuthal projection of the sphere centered at the red ball. This lets you do vector math as if you were in a simple 2D space, so it’s very easy to add forces and integrate for velocity.

I also re-wrote FlexiLine on the spherical plane. See the sketch here.

# Concepts, pt 1

I’ve been thinking for a while about a programming language that tries to make as much as possible explicit and controllable. That is, a language that has the mechanisms to define and program core features of the language itself. I think this would solve a large number of programming annoyances and problems, because I believe that the problems are caused by a) unexpected or unwanted consequences to the formal rules and mechanics built into languages, and/or b) a lack of abstraction and reference mechanisms. For instance, consider writing a singleton object. A singleton is basically the combination of a class and its associated type, plus exactly one instance of that class. We group these multiple concepts together as a single conceptual unit, which we call the singleton. In Java, it might look like this:

```class MySingleton {
private static MySingleton instance = null;

public static MySingleton get() {
if(instance == null)  instance = new MySingleton();
return instance;
}

private MySingleton() {...}
}
```

See all that boilerplate? It’s frustrating. It’s frustrating because the concept of a singleton is very simple. But singleton operates on the level of classes, types and instances, which are silent, built in formalities within Java. Java alleviates *some* of the issues by giving you a class for classes (succinctly named Class), but it’s not enough. We would like to write an abstract class representing the idea of a Singleton, but Java doesn’t even come close to giving you the capabilities.

The Java concept of a “class” tries very hard to be isomorphic to – or “equal to” – our mind’s concept of “concept”. When we write something like “class Dog extends Animal” in Java, we’re trying to map out a one-to-one, invertible relationship between our mind’s concept of a Dog and OOP’s “concept” equivalent, class. Keeping this connection accurate is incredibly important to our ability to comprehend a program, because it allows us to reason and attach meaning to the program in a manner we’re very familiar with – reasoning in our own mind.

Let us call this connection the Conceptual Function. It is actually a pair of functions: the first takes concepts in our mind as input and outputs concepts in code; the second takes concepts in code as input and outputs concepts in our mind. These two functions should be inverses of each other. We strive, in programming, to adhere to that principle; to keep the Conceptual Function as nice and clean-cut as possible – more formally, to make the Conceptual Function both one-to-one and onto (I’m abusing definitions here since we want BOTH functions to be one-to-one and onto, but when they’re inverses of each other the invertibility of one implies the invertibility of the other). “class Dog extends Animal” reads very nicely because the Conceptual Function is invertible; our mind’s concept of a “Dog” is represented very accurately as the Dog class – similarly, the Dog class in Java represents one very clear concept in our minds – that of a dog.

Unfortunately, Java’s class is far from being a perfect representation of a concept. The singleton example shows that. At the very least, classes would have to be first-class members, so that we could, say, implement the singleton as a method:

```public Pair<Class, InstanceOfClass> singleton(Class parent, List<Declaration> body) {
Class newC = parent.deriveClass(body);
InstanceOfClass inst = newC.createInstance();
return new Pair(newC, inst);
}```

This method takes a class and some extra information as arguments and outputs a class and instance pair; obviously this is way out of bounds. Issues arise regarding the definition of sameness and “single”-ton: if you call the method with the same parameters multiple times, then you’d get multiple singletons representing the same mental concept – and boom your Conceptual Function starts getting thrown off. But this issue of “sameness” has been a problem plaguing all programming languages. What if you wrote a singleton in legal Java, copied and pasted it into another file, and then renamed that class into a different class? Are those two the same? This is an issue I’ll talk more in depth about in a later post. Scala alleviates this use case of Singletons by introducing special syntax (‘object’) that basically hooks up the wiring for you, but that’s like trying to cover up all the holes on a sponge by taping bits of paper over every hole – there’s a better, more novel way to solve the problem.

This area of thought is extremely interesting to me and I have a lot to say about it. Expect future posts in this series to be about the Conceptual Function, the mechanisms of naming, mental models and how concepts fit into them, and finally I’ll try to flesh out ideas for a new language to address these issues I’m talking about.