Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Good Tools Are Invisible

gingerbill.org

Post reply on HN
Print view View original

201–210 of 305 posts

Re: Good Tools Are Invisible

#201

Post by iLemming »

stackghost wrote: post #195
reinitctxoffset wrote: post #167

Earlier quoted context omitted.

vi and emacs were designed by legendary computer scientists at two poles of the keystroke latency gradient. Bill Joy was on a model from an apartment in Berkeley, RMS was codifying the collected wisdom of a whole pool of elite typists on TECO and was doing so on the kind of connections at the MIT AI lab. Both of them were more or less stuck with QWERTY. A keyboard interaction paradigm isn't a given chip or a driver f…

RMS may be legendary but he's no John Carmack or whomever else. I use emacs every day, and nobody who does the same can honestly say the foundations are good. The performance is atrocious. The UI locks up when you make network calls because the whole thing is single threaded. The whole thing is a mess of spaghetti code and there are multiple instances of core developers like Eli Zarerski admitting on emacs-devel that…

Emacs is just old. Its foundations (as in the general design) are truly fantastic. I still don't understand how the heck not a single other editor over so many years has even considered replicating ideas like indirect buffers. That alone is a truly brilliant idea, and there are so many more.

Performance is atrocious today. At some point, a couple of decades ago, it might have been considered superb, but some may still remember "8 megabytes and constantly swapping". Emacs can be slow, yet its keyboard latency is still better compared to some other, more modern tools.

I'm not disagreeing with you, Emacs can be so damn annoying, and yet paradoxically remain enormously useful. Sadly (or otherwise), there's still no meaningful alternative to it, nothing even comes close. Lem has a promising story, but I remain skeptical. I think Emacs gets core C improvements sooner than Lem reaches meaningful, practical parity, although I might be wildly wrong in my prediction simply because I don't understand the scale of entanglement of the C-written core of Emacs, yet surely it's probably easier than porting the gigantic body of Elisp in existence to work in Lem.

I can't really comment on RMS' software developer skills - I have never directly reviewed his code. Perhaps, in modern times he'd be considered a "no hire", because being a software developer today requires a little bit more than just being a brilliant code writer.

Re: Good Tools Are Invisible

#202

Post by hiAndrewQuinn »

bensyverson wrote: post #152
m463 wrote: post #150

Earlier quoted context omitted.

> The effect of the interface becoming "invisible" is actually a function of time spent in the interface. emacs starts with "extensible", so wouldn't extending the tool be part of the interface? Purchased tools rarely align with this - they provide functionality over customization. especially in the apple world.

It really depends on the tool… CRMs and EHRs are often designed to be customizable. But end-users typically don't want to spend a lot of time configuring and customizing the interface itself. All the choices quickly become overwhelming.

A "customizable" tool for any task sufficiently complicated to be someone else's profession inevitably results in a tiny micro-economy of configuration engineers who specialize in customizing the tool to be just so.

But the crazy thing is this is still a better solution in the majority of cases than not offering extensibility at all. It turns out buying one piece of enterprise software for $250,000 and hiring one specialist in it for $150,000 per year has historically been a better deal than dumping millions into building it yourself. The gains in efficiency for the fifty $400,000 per year doctors, and 500 $100,000/ye nurses, etc who use it are still worth it.

Re: Good Tools Are Invisible

#203

Post by willtemperley »

Vim is a bad example to use here. I certainly have no hacker-vibe pretensions, I use Xcode almost exclusively, but with the Vim key bindings which have been integrated very well. The productivity gains with Vim commands are impressive.

Re: Good Tools Are Invisible

#205

Post by geeewhy »

word for word why softwares like herdr, haicue, ampcode is getting adopted for ai tooling where it is hot, although just because its cli bound it doesnt mean you cant have elaborate almost-gui text interfaces... lynx is a good example from past.

Re: Good Tools Are Invisible

#206

Post by iLemming »

ventana wrote: post #11

As a long time terminal user, it does not surprise me much when people just don't get it . The discussion often goes like this: — In a terminal, I can do so-and-so with a simple command — Well, in my FrobnicatorStudio, there's a shortcut Ctrl+Alt+So for that and this can go forever, going into pretty much useless comparisons like "in vim, I can delete 24 lines by pressing four keys" (no Sublime user ever needs that)…

Most programmers come to appreciate a single fundamental truth about their field way too late into their careers. That the most basic foundational unit, the substrate they need to conquer is text. Everything stems from it. We have to deal with text our entire lives. It doesn't matter where that text appears - in web browsers, in Jira, in Slack, terminal, in PDFs, Word or LaTeX documents. Code is just structured text. The feeling of empowerment and liberation when you can deal with text on your own terms is a disproportionate multiplier.

Vendors are designed to own you and ownership can have different forms. Slack.app that doesn't let you easily extract code snippets from a thread - owns you. Jira that forces you to use their imbecilic, quirky wysiwyg owns you. Note taking app that keeps the data in their db and not your files - ain't your friend. The friction is the ownership. When extraction of text requires effort, the tool has leverage over you. It's a subtler form than data lock-in - behavioral lock-in. You adapt your workflow to what the tool makes easy, and gradually the tool's affordances shape what you even think to do. Information gets buried in threads, search is mediocre, export is hostile. The "solution" they offer is to stay there longer - search in Slack, link to Slack, screenshare in Slack, summarize with AI in Slack, don't ever leave Slack. The tool becomes the answer to the problems the tool creates. It doesn't become "invisible" like the article says, you just don't realize that you're "lost" yourself in it.

Most popular editors and IDEs don't give you direct leverage over plain text either, at least not without the effort from your side. Shortcuts, popups, UI elements in the IDE at best are local drivers - you can't easily grab a thing from the outside and feed it to your LLM context in the middle of a task, or insert within a comment in the code - you have to switch, copy, paste, deal with format inconsistencies, manual conversion, etc. Then we keep bargaining what method is the best, fastest and most convenient - using the mouse or keeping the fingers on the home row, modality or complex shortcuts. All for the sake of the problem that's artificially enforced on your workflows.

Terminal-heavy users eventually start appreciating the leverage Unix philosophy grants them over text, but that's still contained within locality, they still have to constantly jump around, while eventually figuring out ways for automating some aspects of it.

Anyway, this should be a little more of a deeper discussion than a forum comment. Point is - do not give in to the status quo. Liberate your text - deal with it on your terms. Get annoyed whenever you need to switch back and forth just for the sake of finding the piece you need and moving it around - it should be instantaneous and instinctual. Like boxers moving on a ring and casually throwing punches. Long time Vim and Emacs users "get it", even though often don't follow true - some things never become gratifying instincts. Sometimes, even the opposite forms - redundant muscle memories.

Re: Good Tools Are Invisible

#209

Post by Lio »

An easy to learn UI is not without merit but neither is a complex UI with greater inherent flexibility.

I like old, analogue synthesisers. To pick two very famous examples:

I love the MiniMoog because it's very low friction.

https://en.wikipedia.org/wiki/Minimoog

It's a classic that's simple to learn and quick to get useful sounds. It's a funk bomb.

I prefer the Arp 2600 though (it's the voice of R2D2!).

https://en.wikipedia.org/wiki/ARP_2600

The 2600 makes it really easy to the block signal path so no sound gets out, which can be confusing. Once you learn it though it can do all kinds of tricks the MiniMoog can't.

An Arp 2600 can make two completely different sounds at the same time though and a MiniMoog can't. Bob Moog himself was a fan of the 2600.

Both are classics, still being copied to this day, but for different reasons.

Or to put it another way, a piano is harder to learn than a tambourine. That doesn't make either worse in the right circumstances.

Re: Good Tools Are Invisible

#210

Post by atoav »

I mostly agree with the points made, however I would not call this "invisible" as it was chosen to be called in the title.

Good tools should be obvious, with the main ways to use it being very low friction and low cognitive overhead. That is not the same as them being invisible. It is just a different type of visibility (one that doesn't require users to get a driving license before they can use the tool properly).

When I design such tools, I tend to think about the problem from the users perspective. What is the information they really need to know? In which environment does the rest of the context reside? Which error cases exist, who will have to deal with them and what will they need to know?

Post reply on HN