Great work! I was just thinking the other day how an interface like this would be useful, it seems strange we don't see more UI attempts beyond basic linear chat.
I find most need for managing context for problem solving. I describe a problem, LLM gives me 5 possible solutions. From those I immediately see 2 of them won't be viable, so I can prune the search. Then it is best to explore the others separately without polluting the context with non-viable solutions.
I saw this problem solving approach described as Tree-based problem management [0]. Often when solving problems there can be some nested problem which can prove to be a blocker and cut off whole branch, so it is effective to explore these first.
Another cool attempt was thorny.io [1] (I didn't get to try it, and it is now unfortunately defunct) in which you could mark nodes with metadata like pro/con. Higher nodes would aggregate these which could guide you and give you prioritization which branch to explore next.
Also graph rendering looks cooler, but outliners seem to be more space efficient. I use Logseq, where I apply this tree-based problem solving, but have to copy the context and response back-and-forth manually. Having an outliner view as an alternative for power users would be neat.
Very cool! I created something similar for Casio F-91W. It also uses XState. The benefit of specifying a machine in XState, is that one can embed Stately editor to visualize the states and their transitions.
When a complex system cannot be meaningfully reduced, another approach might be trying to reduce scope.
Current areas include managing services on a server, managing a single-user laptop, and enterprise features for fleet of devices/users.
There is some overlap at the core where sharing code is useful, but it feels way more complexity than needed gets shipped to my laptop. I wonder how much could be shaved off when focusing only on a single scenario.
I like openrc for laptop or workstation. Writing service is as easy as writing a systemd files (with less options of course, but I never really wanted those).
That way you turn a very complex system into a set of much simpler artificial systems that you can control the interaction.
On your example, that would mean having different kinds of configuration options that go for each of those scenarios, but still all on the same software.
One can argue that systemd tries this (for example, there are many kinds of services). But in many cases, it does the complete opposite of this and reducing scope.
Still, I don't think init systems are a wicked problem (and so, it doesn't need advanced solutions to managing complexity). The wickedness is caused by the systemd's decision to do everything.
What I would like to see is something that is to systemd what PipeWire is to PulseAudio.
Before PulseAudio getting audio to work properly was a struggle. PA introduced useful abstractions, but when it was rolled out it was a buggy mess. Eventually it got good over time.
Then PipeWire comes in, and it does more with less. The transition was so smooth, I did not even realize it I had been running it for a while, just one day I noticed it in the update logs.
systemd now works well enough, but it would be nice to get rid of that accumulated cruft.
Also he has no regards for breaking userspace to the point of needing to get scolded by Linus. But some ideas are good and there is a lot of pioneering work that moves the needle. The trajectories of PulseAudio and systemd are similar, it just needs cleaning up. PulseAudio got fixed up by PipeWire, whereas systemd is at the point of lifecycle yet to reach that stage.
Afaik one of the main problem with the software of his is that it tends to sacrifice ergonomics in the 99% common cases for some obscure theoretical observation.
This is of course about tradeoffs and about the complexities of the problems you're solving, but his software is full of choices that only make sense if you priorize elegant code over elegant software only to then grow into something that is neither.
Lennart worked at Red Hat when he was developing systemd. Red Hat's largest customers often have wacky, weird requirements that you would have never thought of unless you were in that specific customer's situation.
There's a podcast [1], which features him as a guest to talk about Linux in general. The main impressions I got from it: he is very confused about what UNIX is and he apparently despises UNIX.
I think he's well suited for his new employer (Microsoft).
The reason that PulseAudio did not work at first (and PipeWire worked out of the gate), is that PulseAudio and PipeWire use a lot of relatively newer kernel audio APIs that previous sound daemons did not use. Therefore driver implementations of those APIs were untested and hence buggy when PulseAudio first started using them.
When people say "PulseAudio is not a broken mess anymore", what they really mean is "my audio driver is not a broken mess anymore".
My "pelican test" for coding LLMs now is creating a proof of concept building UIs (creating a hello world app) using Jetpack Compose in Clojure.
Since Compose is implemented as Kotlin compiler extensions and does not provide Java APIs, it cannot be used from Clojure using interop.
I outlined a plan to let it analyze Compose code and suggest it can reverse engineer bytecode of Kotlin demo app first and emit bytecode from Clojure or implement in Clojure directly based on the analysis. Claude Code with Sonnet 4 was confident implementing directly and failed spectacularly.
Then as a follow-up I tried to let it compile Kotlin demo app and then tried to bundle those classes using clojure tooling to at least make sure it gets the dependencies right as the first step to start from. It resorted to cheating by shelling out to graddlew from clojure :) I am going to wait for next round of SOTA models to burn some tokens again.
mine is seeing if they can implement brown et al (2007) image stitching algorithm. It's old, plenty of code examples exist in training data, the math at this stage is quite well developed, but funnily enough, no decent real open source examples of this exist, especially anything that gets close to Microsoft research's demo tool, the image composite editor (ICE). Even if you heavily constrain the requirements, i.e. planar motion only, only using multi band blending and gain correction, not a single model currently manages to pull this off. Few even have something working at the start. Many other things they excel at, even look downright competent, but in all those cases it simply turns out decent open source examples of the implementation exist on git-hub, usually a touch better than the LLM version. I have yet to see a LLM produce good code for something even moderately complex that I couldn't then find a copy of online.
The reason for MCP is that you get better results with optimized prompts rather than using existing API docstrings. So everybody is going to end up adopting it in some shape or form.
It is a general concept, MCP itself is nothing special, it is that just that Anthropic formalized the observation first.
Tool call = API call + instructions for LLM
So vendors who provide APIs are going to write prompts, add a thin wrapper and out goes MCP. Or you create your own instructions and wrap in MCP to optimize your own workflows.
Exactly, having some metadata on OpenAPI and then have a generic openapi-mcp-gateway seems like a useful approach. Or being it a part of a web framework, given routes also expose MCP endpoint.
The takeaway is to go beyond the bare minimum and put the effort to optimize the docs/prompts, ideally having some evals in place.
For the prompts and resources part of the spec I haven't found much use for those yet. It seems like output of tool calls is enough to get content into the context.
Great work, very cool trick using the clang commands output to get the data.
In my experiments with software visualization I found that generic graph tools like Graphviz or Gephi do not produce useful visualizations for anything beyond trivial size projects. In systems there is always a hierarchical aspect, so hierarchical graphs seem to be clearer as in comparison [0].
Unfortunately, I am not aware of a good open source hierarchical graph tool. Only one seems to be a proprietary Visual Studio DGML renderer. However, this Chrome graph with 140k nodes would also be too much, VS chokes around 25k nodes+links.
>this Chrome graph with 140k nodes would also be too much
I've heard the rule of thumb from Tufte is that a visualization cannot have more than 1000 elements and still be useful. However, I'm not sure he said that and I cannot find supporting evidence...but it seems right to me.
Consider that mapping programs maintain the same level of information density at every level of zoom. I'm not sure, but this might be called "semantic zoom". I remember Microsoft doing a demo of Photosynth (now defunct) years ago which demonstrated impressive results.
One approach would be to play around with grouping nodes in useful ways, perhaps even dynamically according to user input, such that the resulting bundles represent ~100 raw nodes on average yielding ~1000 bundle nodes in the top-level visualization.
I think on the desktop the columns could be wider, so the preview text wraps on fewer lines and more results fit in vertically for quick eye scanning.
Did you think about having the ability to display multiple primary search engines besides Google like DuckDuckGo? A while ago I switched to DDG as my default search engine and learned to trust that the search results are good enough. On occasion, I have a FOMO and fall back to Google anyway. It would be a neat feature to have them shown side-by-side.
Another example is Brave Search. I like the ideas behind it, but will not experiment with it as a default engine as an early adopter due to possible friction. With a meta engine like Swurl I could keep having Google/DDG as the primary engine and include other emerging engines like Brave Search in another column to take it for a low friction/risk test drive (perhaps configured through URL parameters).
I would love to have a different search source, but DuckDuckGo and Brave don't give API access to their results. I would definitely add those if they opened up access to Swurl. Know anyone that could help me with that?
I was so excited I didn't think it through :) This is where wishes meet hard reality. I believe DDG has its own crawler. But they also rely on results from Bing for which they probably don't have rights to provide an API.
So at this point the only viable alternative would seem to be the Bing API.
Just added Bing, you can switch to it from the menu on the top right to enable Bing instead of Google. Please try it out and let me know if that helps you.
VSCode has great and convenient language support, but the trade-off is reduced text editing efficiency, slower speed and more bloat. It is a worthy trade-off in many situations, I use it often when working on projects that are written in languages I am not too familiar with.
I would like to emphasize how big of a game changer the next release of Neovim 0.5.0 will be. With builtin LSP support it will get code navigation, auto-completion and refactoring support on the level of VSCode out of the box, while being way more efficient and faster. I will likely still keep VSCode installed just in case, but only expect it to use it in rare occasions in the future.
Emacs is really powerful, but its age is showing and there are some serious technical deficiencies under the hood. I would challenge the idea from the post that the need for "Neoemacs" is not that great. From the history it appears to me more like that many people tried, but due to complexity of Emacs nobody has been able to successfully pull it off yet.
I've used Neovim prior to trying vscode because it has a language server protocol client extension. Unfortunately, the extension didn't work too well (it had issues with `clangd`) at the time. So, just to compare I installed vscode and was amazed at how polished it was.
Still, I had it in my mind that I wanted to have and fast alternative to vscode so I kept trying to work with Neovim. That is 'till I noticed how much I dislike using vim. You see it has that learning curve that if you've stopped using it for awhile it's a struggle to do basic things. So I used a configuration that made it act more like normal editors. So problem solved? Unfortunately, most extensions are made for a normal vim settup not my easy mode settup. Plus, I started missing having simple things like scrollbars and tabs I could click on and move with the mouse. (I remember the graphical front end for Neovim not meeting these needs at the time.)
So ultimately, I just moved on and stayed with vscode. I would still like an alternative (kedit/k-develop looks promising). However, I'm sort of addicted to the plugins.
That’s amazing news. Native LSP would be game changing. I use coc, but it takes a bit of messing about to get everything working smoothly. Also vscode has has a bunch of extra stuff beyond what’s available via LSP for python now, which is a shame because I’d love to get a full pyright + bells experience in vim.
Very cool project, great to see more s-expression based languages. I maintain a list of lisp-flavored languages [0], so I will add Cakelisp there.
How did you implement the macro expansion? Are you translating the macros to C/C++, then compile it with C/C++ compiler and execute the temporary binary or do you have an interpreter for that?
I work on a somewhat similar project called Liz, which is basically a lisp-flavored dialect of Zig [1]. I did not implement user-defined macros yet, planning to learn more about comptime and its limitations first. But the compiler itself uses macro-expansion to implement many features.
Yes, they are compiled just like the final exe, only they become dynamic libraries that I load with libdl. On subsequent builds, they are loaded again, unless the macro changed.
I find most need for managing context for problem solving. I describe a problem, LLM gives me 5 possible solutions. From those I immediately see 2 of them won't be viable, so I can prune the search. Then it is best to explore the others separately without polluting the context with non-viable solutions.
I saw this problem solving approach described as Tree-based problem management [0]. Often when solving problems there can be some nested problem which can prove to be a blocker and cut off whole branch, so it is effective to explore these first. Another cool attempt was thorny.io [1] (I didn't get to try it, and it is now unfortunately defunct) in which you could mark nodes with metadata like pro/con. Higher nodes would aggregate these which could guide you and give you prioritization which branch to explore next.
Also graph rendering looks cooler, but outliners seem to be more space efficient. I use Logseq, where I apply this tree-based problem solving, but have to copy the context and response back-and-forth manually. Having an outliner view as an alternative for power users would be neat.
[0] https://wp.josh.com/2018/02/11/idea-dump-2018/#:~:text=Tree-... [1] https://web.archive.org/web/20240820171443/http://thorny.io/