sp33der89
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/
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.
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 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.
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.
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!).
Clang is a good example I know, and Scala(https://www.chris-kipp.io/blog/an-intro-to-the-scala-present...) also has some nifty stuff. But even in Scala things aren't as seamless as in Unison.
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'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.
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.
Docs being first class, go-to-definition and all that is one of my favorite things to show off when mentioning Unison: https://share.unison-lang.org/@unison/base
Not saying that array of lines is more performant than ropes, but just adding a datapoint here.
The muscle memory transfers well.
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.
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!
I also hope it catches on, but Unison right now really gives a pleasant experience.
[1]: https://www.unison-lang.org/docs/fundamentals/abilities/
Personally I really am enjoying the one implemented by Unison: https://www.unison-lang.org/docs/fundamentals/abilities/usin...
But Koka's was fun to play around with as well!
However the big problem here being that d2 is still quite new and isn't as well supported as Mermaid JS
> yes! Currently the active development is in dev-fbip, see also our recent tech report: https://www.microsoft.com/en-us/research/publication/fp2-ful... We hope to put out a fresh release after the POPL deadline (Jul 11) that will include the new fip keyword and other goodies.
The dotnet and TypeScript libraries were great as well. All around a fun DB to use, and it builds on PostgreSQL instead of reinventing the wheel.
It's really hard to get people to not-use SQL and one should always look what tool is right for the problem. But I hope a lot of more tools/libraries aim for this kind of enjoyable experience.
Surely there is a lot more nuance for having a nicer database query language than comparing it to JS frontend practices.
SQL is something that'll stick for a long time, but I support attempts from people that don't want to let SQL be the endgame.
Of course don't go around deploying highly experimental shiny things on production! :P
However oh-my-zsh was pleasant to use as well!
Meanwhile I can Google places where I can buy the order pieces. Thank you!
Nonetheless, awesome work!