Live data from Hacker News

Good Tools Are Invisible

gingerbill.org

211–220 of 305 posts

Re: Good Tools Are Invisible

#211
Progressive disclosure is a good framing. Sane defaults keep common workflows fast, while a well-designed escape hatch lets advanced users solve exceptional cases without making every screen noisy.

Re: Good Tools Are Invisible

#212

I agree with Odin creator here. I am not sure when or why we have come to a conclusion in our professional industry that "real software engineer uses vim/emacs/insert your CLI editor here" type of mental model. Is it just the testosterone level speaking here?

Decades ago, really. Before IDEs were remotely as capable as they are now, it was just generally assumed you'd advance from a basic text editor like notepad or nano into vim or emacs.

Re: Good Tools Are Invisible

#213
post #170
post #118

Earlier quoted context omitted.

The article discuses that specific subset of users who are into puzzle solving, so we should ground this discussion around that point and not fall into the “tool x is good/bad” pointless debate.

It wholly does not. It in no way qualifies the statement that people who use tools with "more friction" (the unsound assumption under attack) because they view it as a puzzle game as a subset of the total users of that tool, and devotes zero time to discussing any alternative interpretetations of why someone would do so.

> If people find vim, emacs, or whatever genuinely good and productive, I’m not going to criticize them for using it. People are most comfortable with what they know. But for the people I am discussing, that same familiarity blinds them to their tools’ flaws, and leads them to celebrate those flaws, flaunting them as games.

Re: Good Tools Are Invisible

#214
"I want the defaults to be good and just work, and when I do need to tweak something minor, it should take seconds."

This is Apple's secret, its strange how so many people can't see this or why no ine has comprehensively replicated it.

Re: Good Tools Are Invisible

#215

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…

You’re judging RMS skills based on the current performance of a tool he created 40 years ago using the tools available at the time. That’s wild. You complain about emacs being single threaded but computers in the 80s had a single core. Software at that time was always single threaded. By the time multiple cores became available, emacs wasn’t RMS’s personal project anymore and with lots of users it couldn’t just replace the core to make it multithreaded.

Tell me what Carmack has written that’s still widely used but did not start with the same “problems” as emacs.

Re: Good Tools Are Invisible

#216
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)…

I've never managed to make the terminal work for me. But I've been using windows since I was like 5 and I'm really bad at remembering shortcuts besides a handful of ones I use every day. > When you reach that point, you will be, on average, much more productive than an average GUI user How sure are you about that? I often watch streams of people using emacs or vim, with totally custom setups and it seems like a wash…

Absolutely no one ever has been shown to be more productive because they don’t use GUIs. It’s kind of preposterous to think that could be true.

Re: Good Tools Are Invisible

#217

What is a good tool that's invisible? I'm genuinely curious. All tools I've used are either simple and heavily limited (so, not "invisible" because hard things are hard) or powerful but heavily specialized (so, not "invisible" because the learning curve is very evident). I feel the trade off is inescapable.

[flagged]

Re: Good Tools Are Invisible

#218

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…

sorry for the stupid quesiton, but why do you use Emacs daily if you consider the performance atrocious and the foundations unsound?

Do you have to use it for work? Do you just consider other editors to be even worse, so Emacs is the best of a bad bunch?

Re: Good Tools Are Invisible

#219

Earlier quoted context omitted.

> — Well, in my FrobnicatorStudio, there's a shortcut Ctrl+Alt+So for that When I get those people typically I'll switch to Emacs (it's always open), use dired and rename 20 files at once, using either a keyboard macro I make on the spot or using a regexp replace. This usually not only get them to shut up for good, they also typically then see me as the "computer wizard". I demo'ed some terminal (piping command calls…

I don't think I've ever had to rename 20 files at once, so I wonder if the way people work is kind of shaped by their tools?

The only case I can imagine is when I rename a Java interface and want all implementations to be also renamed accordingly. I can do that in 1 second in IntelliJ. With dired on emacs that would not be possible at all and I would need a tool that can find all implementations first: that requires a LSP on emacs, and then from a xref buffer, not sure how I could rename all classes and their files at once. Probably would need to be manually done? Anyone knows how to do it in emacs with one command?

Re: Good Tools Are Invisible

#220
post #180

Earlier quoted context omitted.

> — Well, in my FrobnicatorStudio, there's a shortcut Ctrl+Alt+So for that When I get those people typically I'll switch to Emacs (it's always open), use dired and rename 20 files at once, using either a keyboard macro I make on the spot or using a regexp replace. This usually not only get them to shut up for good, they also typically then see me as the "computer wizard". I demo'ed some terminal (piping command calls…

When appropriate I use M-S-! or M-S-| to run a shell command in emacs.

Why not eshell?
Post reply on HN