Project Log Entry 2
It’s a command line interface. I know that alienates a lot of users. Even though the visual feedback is limited, it’s the fastest way to develop a freeform interface. Constraints are good. I can focus on optimizing the prorgram at a functional level. I also believe the terminal is a fundamental and important abstraction level.
I started the project using VisualStudio building for Windows for no other reason than that’s what I knew at the time. Since I switched to Linux on my personal machines some time after starting the project I ended up making a commandline tool with CMake and GDB. I’ll likely talk about my big computer-setup-migration in another article.
The most significant challenge with this project was actually defining it. I knew from the start that I needed something for organizing ideas and that I wanted something that could let me work with graphs, given the philosophical motivations for the project. The original vision was something much closer to MS OneNote in terms of the interface. I wanted EMR pen input to create ink strokes much like in the windows ink API. Those would then be saved as SVG files to represent individual “doodles”. Doodles would then be atomized or grouped together as needed and associated in the knowledge base which I called “noodle”. I also wanted intuitive, physics-based manipulations in the editor. All this quickly became a mission to implement a rendering loop with OpenGL and creating an event system to handle user inputs. Although the interface I was picturing would likely be a lot of fun to use, I realized the core concept of the project is really the multiplex graph as a medium for representing ideas. I deferred the fancy bells and whistles and focused in on the data structure.
Once I identified the core of the project I had to decide what level I wanted to implement it at. I originally conceptualized noodle to be a canonical representation of information. If I had thought of a way to implement it in hardware, I might have tried it. But instead I considered implementing the project as a new kind of filesystem altogether, then as a service other programs would dynamically interact with. Finally I settled on noodle as metadata in an existing filesystem.
Although tackling a problem at a lower level gives you more control, it’s better to find the quickest path to the functionality you’re looking for by leveraging existing technologies. This might mean compromising on an idealised version of the project. But at least you’ll have a version of it. And you can always make improvements later.
When I first designed the multiplex graph I implemented it as a node pool which I used to dynamically build adjacency lists. I realized that although memory usage was extremely efficient, the algorithmic execution was slow which could become a problem with larger knowledge bases. Now the multiplex graph uses C++ unordered maps from the standard library. I have yet to stress test it.
I’ll definitely be adding and removing features as I use noodle based on what I find useful and fixing problems as they pop up. The UI needs some streamlining and the only way to find out what works best is by using it.
My short term checklist:
- Replace readline with replxx for compatibility with Linux, Mac, Windows
- Better colours
- UI streamlining and bugfixes. This is about reaching parity with the documentation on the project site, adding new useful things, and killing things that don’t work.