Thoughts about destiny: the prettier for Filesystems

I recently encountered destiny on Twitter, and it’s one of those ideas that instantly appeal to you: what prettier did to code, destiny does to filesystems. I tried this out on my js-rockstars project, and it’s a solid idea. Here’s before and after destiny worked its magic on the filesystem:

It still needs work (it’s very early days), but before I get into that, this is why I believe something like destiny is the future:

  1. Programming is a cognitively difficult job. It takes a lot to actually produce working, elegant code that both does the job and is intelligible to humans. Part of the reason why prettier succeeded I believe, is that it takes away those decisions that doesn’t matter away from you into the hands of a collaboratively agreed upon ideal.
  2. Programmers are nitpickers. We have to be, because we work with a computer that’s the grand daddy of all nitpickers. But if we are let to our own devices, we optimise those things that doesn’t need to be optimised.
  3. All things organisation (& this includes code formatting and filesystem organisation) should be a set of declarative rules that you configure once and then it’s automatically executed by a rule engine. You decide how the organisation should be (because you do that best), and a computer does the actual work (because that’s what it does best, take orders). This is how you make the computer work for you. Or in other words, augmented intelligence.

Now, here’s 3 things I believe can be improved[1]:

  1. Ben has a pretty great video behind the motivation for destiny. It’s a nice watch, but it approaches things almost entirely from the algorithmic angle. Here’s a problem I have, here’s how I wrote an algorithm to solve it. It’s a great solution btw, using trees to model import hierarchy. This is however, not how prettier evolved: it also has a very fancy parser behind it, but the rules were derived from the community. So what destiny needs now is a community-contributed consensus-based rule engine. There is already for e.g. a -S option that avoids single-file folders, but this really needs to expand further.
  2. A “one filesystem organization method to rule them all” strategy probably wouldn’t work. Everybody has got to have their own opinion. Prettier for e.g. has a recommended configuration, but everybody can feel free to tweak this for themselves. A slight niggle when I started working with destiny was that perhaps different top-level folders might also require their own configuration. For e.g, when I ran destiny on the entire src/ folder for js-rockstars, it threw off my entire Storybook stories organization. So I decided to carve off my components/ separately and run destiny just on that. Similarly cypress/ will probably require a different set of defaults. So my current thinking around this is to somehow automagically detect what kind of folder destiny is working with, and apply the best community-created rules for that folder. This is a more nested problem than what prettier had to solve, but it’s worth solving!
  3. Using something like cosmicconfig is an easy first step here: destiny needs to grow beyond its command-line arguments, and cosmic provides the needed footing!

That’s it! I hope the community rallies around destiny or something like it, and us programmers have less silly decisions to take in the future! 🎉


[1] I’ve always believed that unsolicited feedback in open source is not enough. If you talk the talk, you have to code the code. (this came out better in my head). I look forward to contributing to destiny sometime in the near future.

Leave a Reply

Create a website or blog at WordPress.com