Reflection on Light Table from Chris Granger

The creator of Light Table has a critical reflection on it. I love reading stuff like this; It helps me see the mistakes others have made and avoid them myself.

He first talks about BOT. In his mind, BOT is purely data:

In the same way that CES turns a game into one big data structure, BOT has enabled us to turn an entire IDE into a data structure that can be simply introspected and manipulated. 

Sounds great, right? Today, Chris says

BOT filled its goals of an architecture that is infinitely extensible and runtime modifiable, but that degree of power came at a cost - despite its simplicity the resulting program is very hard to follow. I've recently come to understand that this is because mixins are fundamentally an anti-pattern and BOT is basically dynamic mixins.

It's a common pattern for programmers. A powerful idea that makes code simple yet difficult to follow. Inevitably, what is simple to one programmer is always difficult for another programmer.

Here, I think Chris is talking about pushing minimalism and reusability too far:

Mixins hide control flow and add layers of indirection that make it hard to even see what the possible paths through the program are. [snip] ...while you can build a pretty incredible amount of functionality in less than a hundred lines in LT, doing so requires you to pretty much understand the whole system.

Reusable abstractions and composable functions can reduce the lines of code in your program. But such an approach requires the programmers fully understand all the abstractions you use. Understanding new abstractions? That is big ask. One analogy I can make is to understand Chinese. In the Chinese language, we commonly break idiom down to four-character phrases called Chengyu. Because of the complexity of the Chinese language, just 4 Chinese characters can represent a universe of ideas. However, to fully appreciate Chengyu, you'll have to first learn a lot of Chinese characters. Chengyu is elegant, but it takes a lot of investment to appreciate it.

Chris' brutal self reflection is:

This is a failing on my part. I optimized for keeping the codebase small enough that one person could work on it and along the way I ended up making decisions that ultimately made it more difficult for others to contribute.

I see this mistakes made by so many programmers and I try hard to avoid it. Programming decisions have much more impact than just lines of code or performance. To build software that last, an important criteria to consider is participation. One can increase participation via documentation, by marketing, or reducing sophistication to the level of average programmers. Each approach has a cost. Just like anything else in life, programming is about making hard tradeoffs. I don't think Chris means he'll rewrite Light Table in PHP here. No, that'd be taking it to the other extreme. But I do think he'd temper the level of abstractions so that it is easier for the common folks to understand.

I have to give many thanks to Chris for self-reflection. We don't see that enough and it is highly education for the community. I wish him the best on his projects and hope to see more from him.