I suggest making a distinction between non-programmable and programmable systems. We have non-searchable systems, like physical notebooks, and we have searchable systems, like wikis. Going from searchable systems to programmable systems is a similar quantum leap.
One might say that programmability goes beyond the bounds of notetaking, but if our larger domain (exobrain) includes both notetaking and programmability, do we want to mix them or keep them separate?
As a simple example, I can have Google Calendar email me every Thursday morning (programmability). Whatever I put in the event description (notetaking) appears in the body of the email.
Lately I am using Zim Desktop Wiki. I can make links that run batch files on my PC. Those batch files can launch applications or run little Python programs that access a database and generate Zim pages. This is very open-ended, but often with just a bit of programming I can add a feature that I will use a lot.
What do you mean by “programmable”? I keep my notes as a directory of markdown files in a git repo. I can manipulate these files with all the standard Unix command line tools that are specialized for manipulating text. In your mind, does that meet your threshold for programmability, or are you looking for something else?
It’s as simple as doing any other sort of text manipulation with a shell script or Python script, or whatever other programming system one uses to manipulate text. It’s remarkable what you can do with a simple combination of find and sed.
I think this is a good question. Here are some probable components of programmability...
Did it surface most of its actual functionality to users?
A couple different settings: Closed proprietary cloud software, API (how friendly or permissive is it?), downloadable open-source...
How easy (and safe!) it is to call relevant utility functions?
Do you need to close the software to edit it? Did they merely surface the functionality, or did they also leave functions that were highly-exposed, labeled, well-documented, and easy to use? How well do they adhere to various standards, and therefore benefit from skill-transfer? Is it easy to screw up? To revert? What’s the learning curve like?
I’m not sure I agree with the premise of the question. Correct me if I’m wrong, but it seems to me that the question is assuming there’s a single program or system somewhere that is maintaining the wiki, and that this single monolithic system has certain characteristics (open vs. closed source, accessible vs. inaccessible API, etc, etc.). My response is to ask why do we want a single monolithic system in the first place?
In my mind, a personal knowledgebase is a set of texts which capture information that we want to store and retrieve later. Fortunately for us, Unix and Unix-like (by which I mean, Linux, MacOS and Windows-with-WSL) computer systems come pre-equipped with a plethora of tools that have been finely tuned for text processing over a period of decades. I’ve found that by combining the tools already available, I can do most of the things a monolithic wiki system would do with far less configuration and far more flexibility.
With that in mind, I find that my answer to most of your questions is, “Not applicable”. Is it closed proprietary cloud software? It certainly can be, if you store your files in a proprietary service like Dropbox. However, if you store your files in a git repo, which you either self-host or use a more free service like GitLab or sr.ht, it doesn’t have to be. The API, such as it is, is the same “API” you can use to interact with any other file on your computer: GNU command line tools, or if you choose to write scripts in some other programming language, whatever file manipulation API is exposed by the standard library for that language. Same with editing. I choose to use an open source text editor (namely, Visual Studio Code), but there are certainly many competent proprietary text editors, such as BBEdit or Sublime Text.
How easy is it to call relevant utility functions? Well, it’s as easy as invoking any other shell command. Do I need to close the software in order to edit it? Once again, the answer is “not applicable”, because I’m not editing a single piece of software, I’m composing multiple pieces of software, on the fly, to accomplish particular tasks.
Are the functions easy to use and standardized? While we can debate the usability of Unix command line tools for a long time, what cannot be denied is that they are quite well standardized. As for skill transfer, the skills are extremely transferable, insofar as they’re exactly the same skills you’d be using to manage source code in any kind of even moderately sized codebase.
It can be easy to screw up. Command line tools are sharp, and can cut you if you don’t use them appropriately. However, if you have your wiki in a version control system, reverts are nigh trivial. One command and your wiki (or any part of your wiki) is restored to a previous state of your choosing.
While the learning curve on command line tools is steep, I would argue that the advantages that one earns in flexibility, speed (both in terms of machine time and user time), and transferability to other tasks make it more than worthwhile. Of course, if one already knows how to use command line tools with a fair degree of proficiency (as many programmers and technically inclined people do), then the question becomes, why aren’t you using these tools to manage your knowledgebase?
I suggest making a distinction between non-programmable and programmable systems. We have non-searchable systems, like physical notebooks, and we have searchable systems, like wikis. Going from searchable systems to programmable systems is a similar quantum leap.
One might say that programmability goes beyond the bounds of notetaking, but if our larger domain (exobrain) includes both notetaking and programmability, do we want to mix them or keep them separate?
As a simple example, I can have Google Calendar email me every Thursday morning (programmability). Whatever I put in the event description (notetaking) appears in the body of the email.
Lately I am using Zim Desktop Wiki. I can make links that run batch files on my PC. Those batch files can launch applications or run little Python programs that access a database and generate Zim pages. This is very open-ended, but often with just a bit of programming I can add a feature that I will use a lot.
What do you mean by “programmable”? I keep my notes as a directory of markdown files in a git repo. I can manipulate these files with all the standard Unix command line tools that are specialized for manipulating text. In your mind, does that meet your threshold for programmability, or are you looking for something else?
Is it possible to add new features, you hadn’t previously thought of? How easy?
It’s as simple as doing any other sort of text manipulation with a shell script or Python script, or whatever other programming system one uses to manipulate text. It’s remarkable what you can do with a simple combination of
findandsed.I think this is a good question. Here are some probable components of programmability...
Did it surface most of its actual functionality to users?
A couple different settings: Closed proprietary cloud software, API (how friendly or permissive is it?), downloadable open-source...
How easy (and safe!) it is to call relevant utility functions?
Do you need to close the software to edit it? Did they merely surface the functionality, or did they also leave functions that were highly-exposed, labeled, well-documented, and easy to use? How well do they adhere to various standards, and therefore benefit from skill-transfer? Is it easy to screw up? To revert? What’s the learning curve like?
I’m not sure I agree with the premise of the question. Correct me if I’m wrong, but it seems to me that the question is assuming there’s a single program or system somewhere that is maintaining the wiki, and that this single monolithic system has certain characteristics (open vs. closed source, accessible vs. inaccessible API, etc, etc.). My response is to ask why do we want a single monolithic system in the first place?
In my mind, a personal knowledgebase is a set of texts which capture information that we want to store and retrieve later. Fortunately for us, Unix and Unix-like (by which I mean, Linux, MacOS and Windows-with-WSL) computer systems come pre-equipped with a plethora of tools that have been finely tuned for text processing over a period of decades. I’ve found that by combining the tools already available, I can do most of the things a monolithic wiki system would do with far less configuration and far more flexibility.
With that in mind, I find that my answer to most of your questions is, “Not applicable”. Is it closed proprietary cloud software? It certainly can be, if you store your files in a proprietary service like Dropbox. However, if you store your files in a git repo, which you either self-host or use a more free service like GitLab or sr.ht, it doesn’t have to be. The API, such as it is, is the same “API” you can use to interact with any other file on your computer: GNU command line tools, or if you choose to write scripts in some other programming language, whatever file manipulation API is exposed by the standard library for that language. Same with editing. I choose to use an open source text editor (namely, Visual Studio Code), but there are certainly many competent proprietary text editors, such as BBEdit or Sublime Text.
How easy is it to call relevant utility functions? Well, it’s as easy as invoking any other shell command. Do I need to close the software in order to edit it? Once again, the answer is “not applicable”, because I’m not editing a single piece of software, I’m composing multiple pieces of software, on the fly, to accomplish particular tasks.
Are the functions easy to use and standardized? While we can debate the usability of Unix command line tools for a long time, what cannot be denied is that they are quite well standardized. As for skill transfer, the skills are extremely transferable, insofar as they’re exactly the same skills you’d be using to manage source code in any kind of even moderately sized codebase.
It can be easy to screw up. Command line tools are sharp, and can cut you if you don’t use them appropriately. However, if you have your wiki in a version control system, reverts are nigh trivial. One command and your wiki (or any part of your wiki) is restored to a previous state of your choosing.
While the learning curve on command line tools is steep, I would argue that the advantages that one earns in flexibility, speed (both in terms of machine time and user time), and transferability to other tasks make it more than worthwhile. Of course, if one already knows how to use command line tools with a fair degree of proficiency (as many programmers and technically inclined people do), then the question becomes, why aren’t you using these tools to manage your knowledgebase?