I had an interesting exchange with David Buchan over the weekend regarding Mentat.
I’ve done a very bad job articulating, even to myself, what Mentat is supposed to be. This monograph attempts to lay out the foundations of that.
Applications have become a very common part of our life. I spend a big chunk of every day in my web browser or email applications as I guess you do. Unless you are a developer you probably don’t think too much about them except for the odd gripe or chafing when they don’t work the way you would like.
Every application is a function of a series of choices, made by the developers, about how they should work. Those choices are themselves a function of a series of beliefs about what their application should be.
To the extent that your beliefs about what any given application is for, and your preferences about how to do the work, mirror those of the developers you are likely to be more or less happy with your experience.
This leads to a situation in which some applications are arbitrarily limited by their developers. The developers simplify what is possible into a set of (they hope) good choices that will suit the most users. For those users, the lack of available choices can be a blessing as the application feels like it fits them.
However, if you’ve had the experience of working in such an application when it doesn’t match your preferences — it can feel painful, cramped, unintuitive. It is, I’ve always suspected, how left-handed people feel when given right-handed scissors.
At the other extreme are applications that can be extensively customised. That is to say that if you don’t like the default behaviour of the application, that behaviour can be changed to better suit your preferences.
The downside of this approach is complexity. Every choice must be customised and that can lead to a mess of configuration choices that are hard to understand or predict. We can see the difference if we consider the configurability of two popular text editors (and not counting those options relating to fonts, style, or programming language syntax):
TextEdit — 26 preference choices
Sublime Text — 113 preferences
Sublime Text can be extensively customised but at the cost of a much steeper learning curve compared to TextEdit since you have to understand what those options do and how they interact with each other and with the tasks you are trying to perform.
If you are spending a lot of time in your editor (as developers, a prime target for Sublime Text, often do) then it can be worth it as you may, ultimately, become far more productive at editing tasks than someone who sticks with TextEdit.
While there is a huge difference in the kind of text editor they are, both TextEdit and Sublime Text are definitely text editors. You wouldn’t suddenly find yourself reading your email or doing your taxes in either of them.
Doing your taxes is maybe a stretch but reading & writing emails. Why wouldn’t you use your favourite editor for handling what are, for the most part, text editing tasks?
Well probably because the developers decided that being an email client was not an important part of being a text editor. This is about the choice of what an application should be. It’s purpose.
Emacs is another text editor that, like Sublime Text, offers a huge amount of possibilities to customise its behaviour. But there is something else about Emacs that sets it apart even from editors like Sublime Text: Emacs is also a platform.
In the computing world, a platform is something that you can build applications upon. For example, macOS is a platform. It an environment (which is a kind of Application we experience as a widow) that offers a rich set of APIs on which other applications, like TextEdit, can be constructed. But TextEdit is not a platform. You can’t build anything new on top of TextEdit. It will always be a text editor.
So when I say that Emacs is a platform what I mean is that it provides the infrastructure on which other things can be built. In this example, Emacs is really two things sharing one name: Emacs the platform & Emacs the text editing application that runs on Emacs the platform.
The macOS platform provides the Objective-C (and Swift) languages and the Cocoa API to create applications that run within it. The Emacs platform provides the Emacs Lisp language and APIs for displaying & managing text to create applications that run within it.
Much of the behaviour of Emacs the editor is written in Emacs Lisp. If you don’t like how the editor works it is possible to change the source code and alter its behaviour at a fundamental level. Or if you want to do something completely different you can write new source code to create new functionality and new applications that live within it. Indeed people have written email clients, outliners, and even web browsers inside Emacs!
Another example, that is less well known but closer to my heart, is Radio Userland written by Dave Winer. Radio was an application for reading RSS feeds and publishing a blog. But, under the hood, both of these were implemented atop the Frontier platform with its Usertalk language.
This meant that Radio could be extensively customised, re-written, and extended to handle new needs. And lots of us did that. In my case, we built a tagging framework on top of Radio that allowed us to create an online service for the semantic aggregation of blogs.
All of which brings me back to Mentat (If you got this far I guess you are wondering where I am going with this).
There are lot of applications for managing structured and semi-structured knowledge of different kinds. But, like TextEdit, they are applications. Their purpose and their behaviour, while customisable to a greater or lesser degree, is fixed.
For example we could see a ‘To Do’ list as a form of semi-structured information. What I mean by ‘semi-structured’ is that there is an overall shape to a ‘To Do’ list but within that there may be a lot of flexibility about an item in the list.
It seems like every week someone launches a new To Do list management app which has a slightly different twist on the purpose and bundles a different set of features to fit a different kind of audience. Some are simple like the iOS Reminders app, good for remembering what to buy at the supermarket, some are complex like Asana, good for coordinating large projects involving dozens or hundreds of people.
Email too is semi-structured. You have an inbox that contains a list of messages and each message has metadata fields (e.g. ‘From’, ‘Subject’, ‘Sent’) and a body that could contain anything. There are dozens and dozens of different email clients again ranging from the simple to the complex.
Semi-structuredness is not, I think, binary but a spectrum. A novel or a poem could be considered unstructured as it is a flowing series of words and punctuation and authors often play with the format. On the other hand, a novel could be considered to be structured in that it’s words under chapter headings and those chapters create a structure. File formats like SGML & XML are attempts to map structure onto essentially unstructured text.
In my own realm, I have discovered an explosion of semi-structured information that I try to grapple with and make use of. Things like facts (though I might not formally label them as such), notes, to do’s, links, bookmarks, books, and especially questions. I do like a good question.
Over the years I have been through many different applications that attempt to help me wrangle such things. They have been successful or unsuccessful to some degree as they have fit my needs or not. But none has ever truly stuck.
Right now I am making a lot of use of Roam Research which describes itself as ‘A note-taking tool for networked thought.’ In practice Roam is a browser-based outliner, editor, and cross-referencing tool. It is very good at what it does and, indeed, it caused me a big problem for Mentat because it did some of the core things I wanted to so well that I signed up for 3 years and more or less abandoned Mentat.
However I can already see the cracks. The developers of Roam have a vision in mind and… it’s not my vision. They have a set of priorities for what they work on and… it is not my set of priorities. Decisions made in how Roam is implemented have serious consequences for how it can be used.
As much as I use Roam now and think it’s a great app, I can’t see myself using it 5 years time and certainly not in 10. But do I think that semi-structured information will still be important to me then?
There’s one other thing about Emacs that I think is worth mentioning. It was first released in 1976 and has been in constant development to this day. In 1986 GNU Emacs was released that included the Emacs Lisp language making Emacs truly a platform. While there have been many changes a user of Emacs today would recognise the same application from 30+ years ago. If you learned Emacs in 1986 you could still be using it today.
My conjecture is that this is because Emacs is a platform that exposes much of its funtionality via Emacs Lisp. This means that the applications built on the platform can be customised to fit the needs of the user of the platform and that they can evolve as those needs shift.
Evolution is perhaps the missing aspect of applications vs. platforms. When something is delivered as a platform it allows the user a great latitude to customise applications to fit their needs and to evolve those applications as their needs change.
What I have not found to this date is a credible platform for working with (both individually and in a group) semi-structured information on which I can build the kinds of application that I want to use, working the way I want to use them, and evolving with my own agenda (which has also changed drastically over the years).
I want a platform that, like Emacs, could still be relevant and useful thirty years from now!
Mentat then is an attempt to create such a platform. To create a platform that can store, manipulate, receive/transmit, and visualise semi-structured information and an environment for building applications that depend upon the information stored.
