rcbarnes

Well, from what I gather, the overarching criteria of the contest for which this was develped is "Does it do something novel to advance understanding and execution of software development?" While that kind of focus tends to bring out all kinds of wacky ideas, don't confuse defiance of the status quo for casting off all reason. When there's no shame in it, experimenters needen't rationalize or smooth over their deviation from expected norms.

Wow, I'm seriously considering adapting this for my shell scripts (with code recovery via mercurial, since I'm weak of will...). Actually, I bet there are already others doing the same, because code deletion in personal shell scripts probably turns out to be an unalloyed good.

Consider this: you've got some script that does a sequence of operations using the standard tools. Somewhere you change between imagemagick and graphicsmagick and some image doesn't get made thanks to syntax differences; after this you've used some clever shell filename expansion expression or regex to move/delete files, but the missing image changed your working context enough that suddenly you're in $HOME doing an rm -rf .! The environment is just too fragile and powerful to completely automate everything you might need without setting up enough safety mechanisms, confirmations, and sanity checks to largely nullify the value of scripting as a nearly zero development programming toolchain.

But if shell code were trivially spec'd for pre-/post- conditions and misbehaving code gets noisily deleted (noisily so everything isn't packed away into code versioning purgatory by cascading failures when a tool like rename is accidentally uninstalled)---especially if the shell of pre-and post conditions were left around stub code... Imagine the beauty of your scripts directory!

Replacing some slain block of code is trivial since the tools you need are already mostly written, and you've done something close to what you need before---plus the whole point of shell scripting is that it should be effortless and fast to produce.

If you've built a massive, multi-purpose utility, it deserves to live only as long as it runs flawlessly---after which, you should slice it down or replace it with an inevitably more reliable equivalent that was written for the same purpose years (or decades) ago.

Best of all the conditions that deleted your broken cruft even remind you exactly what you needed to do when you're re-implementing something, but often without pre-studying the entire system to ascertain what world state you are getting and what you need to produce. Brilliant!

This may have started out somewhat tongue-in-cheek (since most programming environments are at least somewhat stable and feature significant error detection and recovery facilities), but I think there's some dead serious application in the quick-and-dirty, often unchecked and fluid environment of traditional shell scripting. The more I think about it, the more I'm amazed my quarter million keystrokes of live scripts woven into my every task on my Linux desktop haven't produced more catastrophes (or any meaningful accidental data loss) or left a trail of silent failures for me to find only long after the causal bugs had manifested.

Yeah, I let hjkl discipline slide for a long time, too; it's damn hard to interrupt a reflexive reach for the easier to align cluster whose labels actually correspond to what you want to do. Here's the part that finally pushed me over: arrow keys can supplement/mirror/tweak anything you find overly awkward, slow, or hard to remember in the "native" form. And you can remap them straight (no prefixes/modifiers) or build something arbitrarily deep and be certain you won't interfere with any other bindings.

See? the arrow key scan become four more user keys, and they have easy to remember direction/orientation if you need it. Having trouble navigating, swapping, and resizing, your layout (and accidentally hosing text with ^w in the wrong mode? I did, but 20 minutes after seeing someone else use a similar setup, I was using my own variant more comfortably than any console window management bindings I'd ever tried before.

tl;dr; Remap the arrow keys from movement to anything you struggle with normally, and be amazed how you survived before your four newest "user" keys were liberated!

(Also, if anyone wants me to, I'd be happy to post my re-binding config lines as a template/sample.)

My theory is that the logic behind such claims is that you can effectively map all groups of folders' entries using tags derived from every file's original folder hierarchy, but representing all the possible groups of tagged files in a hierarchical folder system requires an incredibly fragile and complex system of symbolic links. Ignoring certain issues with converting folder names to tags (such as two identically-named folders nested in the same path and collisions between tag combinations whose paths are a different order of the same set of folder names), an ideal tagging system is as expressive as any hierarchical organization and it is capable of numerous additional ways to slice the data.

In practice, tagging systems seem to be limited by relatively immature interaction models relative to the far better explored nested structures. For example: for a given folder in the hierarchy there are often few enough children to allow easy recognition of a forgotten name whereas tags for non-empty subsets of a given set of files are hard to suggest meaningfully; nested folders demand more care beginning with the earliest placement of files but tagging makes wholly unsustainable conventions perfectly reasonable early on; sections of nested structures are easy to relocate to a new parent but changing the related set of tagged files to uniformly substitute comparable target labels for precisely those obsolete labels is difficult or impossible.

In short, there's a theoretical basis for replacing folders with tags, but the real-world adoption is severely hampered by grossly incomplete UIs for many needs previously met by nested folders.