I hope org-mode gets more popular outside of Emacs. I know all the words already about how org-mode is great because of Emacs, but the way you can do plaintext outlining, with great support for TODO's, in org-mode is fantastic. It retains a lot of readability, and that isn't Emacs specific: there are things that make org-mode great as-is!
A small todo application for mobile that uses org-mode as the database doesn't need to parse fancy org-babel stuff, except maybe that org-mode itself can be hard to parse.
Personally I'm hopeful that org-mode gets some more love outside of Emacs, so here's a list of interesting org-mode projects that aren't pandoc or Emacs related:
That won't change until top-notch, simple (i.e., without 100 transient dependencies) org parsing and formatting libraries for a few key languages (go, javascript / typescript, and python; maybe also C++ and java) become available.
Which is sad because org-mode seems far more versatile than markdown, except for a couple of ergonomic features (e.g., ``` vs #+BEGIN_SRC, and * [x] task vs * DONE task).
Even libraries to parse and format a subset of org-mode would be good enablers.
I think it gets away with being more verbose because those two aren't spelled "#+BEGIN_SRC" and "DONE", they're "C-c , q" and "C-c t d" (from memory). I think unless you really commit to learning a decent subset of what org-mode provides the ergonomics are always going to seem a little clumsy. I've always found emacs shortcuts hard to learn, and because of that I've never quite got my use of org-mode over the activation hump to really stick for the long term. Every time I leave it and come back to it I have to relearn a lot of it from scratch because there doesn't seem to be any sort of intuitive framework I can hang it all off.
I made my own macro* to encapsulate the currently selected text in SOURCE \END_SOURCE tags. Now you're telling me there was a keyboard shortcut for that?
What else I don't know about emacs?
*It was my first macro/function and while creating it I've learned that 1. It wasn't that hard and 2. With help of an LLM you can program emacs a little even without deep knowledge of elisp. Though LLMs suggest very unreadable elisp code and you have to rewrite everything.
I sort of bounce off of org over and over because I find it very unreadable. Compared to Markdown (I know Markdown isn't quite the same thing), org feels very crusty and noisy.
While org mode can do almost anything, it is foremost an outliner, not a markup language like markdown. Using org-mode in place of Markdown is like using MS Word for coding, so no wonder
I think you are right. My real issue is that I don't have an "outliner" brain. I've never really understood why people make outlines or even, really, take notes.
Org's utility to me is then the making and keeping track of todos. But markdown can do that without much trouble.
I actually pandoced my Markdown files to Org mode a few years ago because Org mode is easier to read in plain text editors. I especially like the use of dashes for lists. However, even in Emacs Org mode, I still use `backtick` fences in inline code.
Logseq is probably the closest we had, but it doesn’t quite reach the Obsidian polish and is now moving off of plain text files (somewhat sadly but understandably).
All metaphors break down at a certain point, but power tools and generative AI/LLMs being compared feels like somebody is romanticizing the art of programming a bit too much.
Copyright law, education, just the sheer scale of things changing because of LLMs are some things off the top of my head why "power tools vs carpentry" is a bad analogy.
When it comes to the comparison with other languages like Zig, Rust and Go, I disagree. I think it's because it hits its """new weird thing""" budget really quickly with Abilities and code in a database.
The Share project is open source, in contrast to GitHub, which is also popular despite having forms of locked-inness in practice as well.
I'm saying this not to negate the vibes you feel, but I'd rather people try it out and maybe see how their favorite language could benefit from different design decisions.
I disagree with the author, but I also get the impression that their view of notes is fundamentally different than mine so there's that.
I like the way LogSeq implemented daily notes, UX wise. It's an infinite scrolling page where you can add and edit dailies, so I end up "doomscrolling" my daily notes and re-reading them a lot more often than in other apps.
The developer experience in Unison(and Unison Cloud) has been wonderful for me. I try to write as much in it as possible, for hobby projects or side projects for friends and family.
Abilities(what Unison calls algebraic effects) are really ergonomic too use in practice, the learning curve is a lot lower than a IO monad datatype, and it reads just like Python when putting it to practice!
Code-in-a-database means I don't have to fumble with long compilation times and Git, it brings joy to just hacking on to something in the weekend, because I just get to write code.
The article mentions its drawbacks, and they are real, especially FFI imo. The Unison team mentioned they are planning to include FFI, and it's going to be interesting to see what gets compromised.
But no other language (currently) hits this sweet spot of abstractions(not too little not too much) with an enjoyable DX, for me.
How is the tooling? Usually these paradigm shift ideas fail on interop even if they’re amazing in theory. The ambition level of Unison seems to be absolutely gigantic, so my first thought is that interop with anything outside their idealized world would be poor.
The tooling is surprisingly good for such a "young" language. I've had experience with other budding languages, like Nim, Zig, ReasonML throughout the years(not comparing these languages, just their tooling, they have tradeoffs), and Unison is slick. But expectations should probably be managed, it's not IntelliJ or VS Studio.
I'd describe the tooling as "zen like". When I sit down on weekends to write some Unison, I'll pop up my editor in a left tab, and on the right there's ucm. Since the LSP is included in the codebase manager, I didn't have to setup much. The LSP works good, could use some more code actions to control ucm though.
I'll write some code, throw in a `> ` eval expression to quickly mimic a REPL. I'll see the evaluation on the right.
Eventually I'll switch to the right side and add my pieces. or write a `test>` and expression, which I can add as well to my codebase. Push my changes, create a branch, or switch project also happens.
Maybe I'm not sure what the name was of a piece of code? Or I'd like to be able to search based on function signature. Both can be done in the right tab(ucm) with the command `find`.
Documentation is first class, I can browse the doc comments attached to variables/functions/types, I can link other terms(pieces of code) in those docs and they are discoverable as well, as soon as you add it to your codebase.
I believe a big part of why this is all possible, is that when your code is stored like this, it makes tooling around it a lot less complex. No need make ad-hoc parsers, compilation caches, syntax checkers. I'm no tooling expert, but for example making a visual editor based on the terms in your codebase sounds a lot easier than making a visual editor for TypeScript, the mental gymnastics is a lot less.
ISTM that packing all that goodness (?) into the compiler stack itself is moving away from what I want where the compiler is a plain-Jane source transform and its inputs and outputs are very well specified and predictable. That’s where the ecosystem of tools comes in, and when done right I think tools should be very easy and straightforward to use and create. I often feel modern languages get this wrong by “including” too many “batteries” instead of specifying and documenting their build / dependency semantics clearly and providing good tools or libraries for working with and composing those elements of build.
Far too few language ecosystems provide any kind of libraries for it whatsoever, even for working with syntax / AST. I really can only think of Clang and Go, and Go’s tool libraries aren’t very accessible IMO.
This is a good point, and deserves a lot more discussion about it.
I personally don't mind that my code is somewhere else than in a text file, because as it now I have to ductape a huge array of tools to make it to production in languages like TypeScript and Elixir(languages we use at $WORK). I don't want to deal with that anymore than I need to.
I hope modern languages get to the level of swiftness like Unison, but until then I'm really happy with Unison, because code-in-database is only one of the several aspects I like about it(no dependency conflicts being another huge part of it!).
Unison does things very differently, and it might not be everybody's cup of tea. But I do hope that popular languages take the good bits and help programmers do less chores and more fun stuff.
> I often feel modern languages get this wrong by “including” too many “batteries” instead of specifying and documenting their build / dependency semantics clearly
Do you have some examples? Nix somewhat aims to solve this, but it has its own drawbacks.
A lot of people these days _expect_ a battery included environment: package manager, build tooling, linting, formatting, a language server, documentation generators. Unison solves a lot of these in one go because of the way it handles code, I think that's elegant and worth exploring.
I’m not sure there is really more to say here. A lot of people don’t seem to like strong type systems very much either, but that doesn’t mean they’re not wrong. ;)
That said, it clearly has some interesting ideas! I’m just not sure I understand why the database needs to be the compiler. It seems like an awful lot of design decisions baked into the stack instead of offered as APIs or protocols. And it’s obvious that we can consider the filesystem itself to be a sort of database — Git famously is implemented entirely in filesystem semantics, for example, so it’s also not clear to me why this content addressing can’t simply be done in a cache dir, or some such, the way many build systems do for their compilation units.
I'm sure that there can be some very interesting discussions about code-in-database and interop with tooling!
> I’m just not sure I understand why the database needs to be the compiler.
I'm not entirely sure if these two are tightly bound. For example `ucm` uses a SQLite database, but Share(their Github equivalent) uses PostgreSQL afaik.
I believe a previous iteration used Git as the backing store but they didn't go through with it. I'm not sure about this tho.
Using meow:https://github.com/meow-edit/meow I actually got keybindings in Emacs that are helix-like, so I use helix for certain projects and Emacs for others.
I absolutely don't mind the plugin system being a Scheme. It's a plugin for a text editor, and Steel(https://github.com/mattwparas/steel) seems to be a lot less of a maintenance burden than WASM plugins(besides that I find the WASM tooling to be extremely complex).
But besides all that, Helix learned be that I don't need fancy plugins or endless finicking with config files and toolchains. Using a combination of other tools, like yazi and lazygit, helps me not only inside my editor but outside of it as well. And Kakoune does this even better. In that regard it has been a real eye-opener and refreshing. The downside is, it's hard to go back to other editors!
While I understood the maintainer's arguments for wanting to adopt a Scheme-like for plugins, I can't help but be a bit disappointed.
Helix being written in Rust meant that I felt very comfortable looking at the source code which gave me the confidence that if I wanted to implement something, I could reasonably do so. Furthermore, the idea that plugins could've been in Rust or Rust through WASM meant that I'd have an editor which was completely hackable in the least annoying way possible. Every time I have to learn one of these tool-specific languages I end up breathing a heavy sigh, spending a lot of time relearning things or working around weird quirks, and then ultimately giving up after writing the most basic version of what I want to do.
Ultimately, this is just a me problem and I really can't complain about something I haven't paid for or substantially contributed to. Maybe it'll actually be awesome and I'll change my mind completely, maybe they'll reconsider and add Rust-based plugins. Helix as an editor is awesome and I'm just going to have to trust the developers.
But you are also speaking as someone who already knows Rust. If we take a step back and imagine someone who knows neither, what's easier to learn, a high level language or a low level one? (I don't think pointing out that Rust has high level aspects alters the relative situation)
Take two programs with historical success in building this kind of plugin system: Emacs and Browser. The number of non-programmers who can write elisp (or javascript) but won't dare to touch C/C++ code in the core layer probably outweighs the opposite by a huge factor.
Just to be clear, this was one of the arguments of the Helix maintainers. I (sort of) agree and do think it's the _overall_ better approach in terms of general learnability and ease-of-use (bar WASM+WASI components, though that has it's own complexities).
However, my complaint was a bit more selfish-- for me personally, I'm a bit let down because I had gotten the idea in my head that I'd be able to use Rust from top to bottom. Following the discussion for the plugin system for a good while, many different options were on the table and I had gotten my hopes up for the ones which didn't pan out. Woe is me, but I'll live and I trust the maintainers to do what is ultimately right for the editor.
The original issue wrt. WASM for the Helix project was that WASM currently only exposes a very barebones, C-like FFI for communicating with plugins. This should be solved in the future by the WASM component model, so these choices could well be revisited.
Agreed -- I've been putting in some significant effort to learn helix / break my nvim habits specifically because it's written in rust so I feel like I could hack on it / contribute back.
> Furthermore, the idea that plugins could've been in Rust or Rust through WASM meant that I'd have an editor which was completely hackable in the least annoying way possible. Every time I have to learn one of these tool-specific languages I end up breathing a heavy sigh, spending a lot of time relearning things or working around weird quirks, and then ultimately giving up after writing the most basic version of what I want to do.
I very much understand this. However I'd argue using Scheme is a great tradeoff. Because in the end programming is about tradeoffs.
Scheme will not overcomplicate plugins for the maintainers, and as a write you have to learn a tiny DSL for configuring your editor.
As we speak, I'm trying to write a plugin for Zed, and as awesome all the niceties about Zed is, plugins are not easy, and frankly speaking, I feel like I wasted my time with all this nonsense about WASM, while in Helix the same plugin (language support) was really, really simple, even as somebody who knew nothing about Rust or Scheme.
This, plus abilities[1](what Unison calls algebraic effects), make Unison such a joy to work with, it's a very pleasant experience. You can get straight to the business logic.
I also hope it catches on, but Unison right now really gives a pleasant experience.
A small todo application for mobile that uses org-mode as the database doesn't need to parse fancy org-babel stuff, except maybe that org-mode itself can be hard to parse.
Personally I'm hopeful that org-mode gets some more love outside of Emacs, so here's a list of interesting org-mode projects that aren't pandoc or Emacs related:
- https://github.com/RWejlgaard/org - https://nvim-orgmode.github.io/ - https://github.com/haxscramper/haxorg - github.com/cnglen/windancer - https://braintool.org/