Posts labeled tanagram

  1. Tanagram Demo #2

    I've been working on a new way of writing and working with software. This is the second demo (demo #1 here), and although this, too, looks like a toy, I think it's a good encapsulation of what I'm trying to solve with Tanagram. In short, Tanagram is a programming environment that's trying to make it easier to browse codebases and write glue code (i.e. boilerplate code; code where remembering the exact syntax is harder than the logic itself) by putting codebase concepts into a database and replacing some typing with a GUI.

    It doesn't look very impressive. After all, it's just a bunch of stock AppKit controls in a haphazard UI, and there are many obvious additional features I could build. But this isn't meant to be a feature demo; instead it's a small illustration of how I'd like to be able to build software. To put this illustration in perspective, I'd like to first talk about the problems I have with plain-text codebases.

    Continue reading →
  2. Tanagram Demo #1

    I've been working on a new way of writing and working with software. Although it's still very early along and looks very much like a toy, I'd like to share a demo:

    Tanagram is an attempt at alleviating personal frustrations when using and making modern software. In many apps, I often feel limited by the feature set that the interface enables; I can imagine customizations and automations that are simply inexpressible through the UI. Sometimes, I may theoretically be able to build what I imagine by integrating with some APIs, but doing so would be a major context shift and involve a despiriting amount of boilerplate code and incidental complexity. A lot of these are small ideas for which the overhead in configuring the build environment, finding and installing dependencies, and deploying the code dramatically outweighs the effort and reward of the project itself.

    Continue reading →
  3. The Database Inside Your Codebase

    Navigating codebases of any meaningful size is difficult. Most of a programmer's time is spent jumping through the codebase, reading or skimming to build a mental model of the constructs and conventions within it. These constructs — among them: the DSLs, interfaces, and taxonomy of types that exist — are arguably the most important precursor to understanding where and how to make changes. But these constructs only exist in programmers' heads. It's difficult or impossible to navigate most codebases through the lens of those constructs; programmers lack "code browsers" that present the underlying code independently of files and the filesystem hierarchy. Yet code browsers that can do so — and we'll look at some examples below — would be incredibly useful. This is because instances of these constructs can be thought of as records in a database, albeit an ad-hoc, poorly-specified database that can only be queried through carefully-crafted regexes.

    In simple cases, some constructs manifest as naming conventions: prefixes in a name may be a rudimentary way to namespace classes, while suffixes may be a rudimentary way to group classes or identify their type. But these are easy examples; many patterns are much more subtle.

    Continue reading →
  4. Computers Have Gone Wrong (And It's All Software's Fault)

    Computers Have Gone Wrong (And It's All Software's Fault)

    You're reading this on a computer. It is likely one of the most powerful individual computers ever made. You probably have a few more of a similar caliber nearby. What can you do with that power? Can you get it to help you keep track of some kind of information that's important to your life, and then search through that information in a useful, reliable way? Can you enlist your computer to compute some insights — or just some arithmetic — that you care to know across the information you've collected? Can you do it all in the specific way that you would like to do it?

    Continue reading →
  5. Building A New Blog

    I've moved my blog off of Wordpress — in part because of limitations with's hosted offering — and onto a custom-built site.

    I mainly did this to serve as a proof-of-concept for implementing a blog on the first primitives that come from Tanagram, a project I've been tinkering with over the past few months. Tanagram is, in part, a bunch of simple, transparent data types and functions that operate on those data types and return updated data. This, I hope, will make it much easier to build boring software — and that's a good thing! Most software ideas are essentially variations on cookie-cutter themes, and Tanagram should provide the setup and primitives to make the process of building software like that as quick and easy as, say, writing an essay.

    Continue reading →
  6. Computers Aren't Fun Anymore

    Throughout The Dream Machine, a history of the early days of computing, tinkering and having fun was a recurring theme throughout the decades. I wasn't around to experience the early days of computers myself, but they seemed to be genuinely exciting and rewarding. In the words of MIT sociologist Sherry Turkle: computers empowered their users, making them feel smart[er], "in control", and "more fully participant in the future".

    Those feel like odd descriptions for the modern computing experience. Using computers today doesn't feel like an empowering experience. Sometimes it's mindless and distracting. Sometimes, when a redesign rolls out, or laptop doesn't wake from sleep mode, it's downright hostile. The experience of using a computer in 2020 is a concoction of data silos, dinging notifications and reinvented wheels, presented in gratuitously bubble-wrapped UIs hyper-optimized by persnickety product managers and soulless A/B tests.

    Continue reading →
  7. Documenting Some Thoughts Around Tanagram

    Tanagram is the name of a project idea I’ve been thinking about for a while. I trace the idea’s lineage back to a little prototype I built in late 2013. I didn’t think much of it at the time, but I’ve revisited this idea (or at least something directionally-related) countless times in intervening years.

    With the free time I’ve had lately, I decided to gather my scattered thoughts and define what exactly I want to build, distilling many vague ambitions into specific product features. I treated it as an exercise in articulating my thoughts, as well as a singular place to point people to when I’m asked about the project (it’s rather complex to explain!). The result is a rather long read.

    Continue reading →