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

281–290 of 305 posts

Re: Good Tools Are Invisible

#281

Post by iLemming »

necrotic_comp wrote: post #21
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)…

Exactly this. The non-composability and non-standardization of GUI tooling is my main issue with them ; having the same toolkit available to solve every problem takes some doing but is ultimately more efficient. That being said, it's a hard sell. It's not easy to grok the simplicity of the commandline tools until you've used them to solve what would otherwise be an intractable problem.

Yes, any GUI that doesn't provide any kind of RPC or composable API layer is almost a lost cause to me. I'd personally refuse to use it. With a caveat, though: on MacOS, which I absolutely abhorred in the beginning, having now been required to use for work (instead of Linux), I found the beauty of OSA (Open Scripting Architecture). Holy mother of Turing, I wish there was anything similar on Linux. I had no idea how amazing this thing was. I can fearlessly dig things out of even complex UIs for automation in ways that I can't ever dream to be able to do on Wayland. That still not an excuse - any serious UI should provide a functioning API.

Re: Good Tools Are Invisible

#282

Post by [deleted] »

bombela wrote: post #178
jrimbault wrote: post #13

Having designed a good number of internal tools for teams of developers I couldn't agree more. Earlier I had the tendency to "leave the guts" open, thinking my users were developers and would want that. All it did was put obstacles in my teammates actually doing their work. My teammates must use the tools I made for them to achieve work the company needs them to do, they don't want, nor should they want to, fiddle wi…

And before any major change, add a `--v2` for early adopters and `--v1` as default. Nobody should notice anything on `--v1`, any regression must be fixed imediately. Flip `--v2` as default, leaving `--v1` for the unforseen. Until you can finally get rid of them. This helps being as invisible as possible.

[deleted]

Re: Good Tools Are Invisible

#283

Post by faustlast »

jshaqaw wrote: post #81

Obsessive hacker tools like Emacs are not a productivity enhancer. But If you find them fun go for it. You are allowed to have fun. You are allowed to enjoy your environment. If tinkering with Emacs is fun for you go for it. It's prob not replacing mental cycles for "productive" work. It's replacing zoning out with social media or YouTube between productive work times. I can't justify using Emacs myself on a producti…

> Obsessive hacker tools like Emacs are not a productivity enhancer.

Emacs wouldn't survive if it didn't provide a net benefit to its users.

Re: Good Tools Are Invisible

#284

Post by brabel »

maleldil wrote: post #263
brabel wrote: post #219

Earlier quoted context omitted.

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…

It would be the same as in IntelliJ. As long as you have the Java LSP active, you issue the `lsp-rename` action: https://emacs-lsp.github.io/lsp-java/#lsp-mode-commands This works exactly the same for all languages whose LSP support this action, which is most of them.

No! Rename in JSP is not intelligent enough to match an interface name with its implementation names and decide whether to also rename those!

Re: Good Tools Are Invisible

#285

Post by brabel »

allarm wrote: post #240
brabel wrote: post #216

Earlier quoted context omitted.

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.

That's a weird thing to say. GUI slows down me A LOT when I sometimes have to switch to it from my terminal for whatever reason. Where did you get your "absolutely no one" data point?

You should read again what I said. Do you think that simply using GUIs makes anyone less productive? You can’t think of any cases where a GUI is definitely better for a task than a terminal? If you think that , consider why the vast majority of people are using GUIs for everything, and only a tiny minority is using terminals for everything. It’s ridiculous, yes, to imagine you would be more productive if no GUIs existed (you just misunderstood my point).

Re: Good Tools Are Invisible

#286

Post by maleldil »

brabel wrote: post #284
maleldil wrote: post #263

Earlier quoted context omitted.

It would be the same as in IntelliJ. As long as you have the Java LSP active, you issue the `lsp-rename` action: https://emacs-lsp.github.io/lsp-java/#lsp-mode-commands This works exactly the same for all languages whose LSP support this action, which is most of them.

No! Rename in JSP is not intelligent enough to match an interface name with its implementation names and decide whether to also rename those!

What do you mean by "implementation names"? I assumed you meant changing the "implements X", which should be easy for an LSP.

Re: Good Tools Are Invisible

#287

Post by zetanor »

maleldil wrote: post #271
zetanor wrote: post #18

I rarely use vi{,m} these days but I sometimes still instinctively type motions or :commands into other terminal editors (which naturally blurts them out into the text buffer). When using something like Sublime or VSCode, I'm always hunting through menus, documentation and search engines to do something simple like ":%!sort -u". Kate is a bit unwieldy—far from invisible—but I've found it to be the most frictionless e…

If you're always reaching for vim commands, why did you stop using it?

Many small reasons; changing workflows, very strange default settings (may have been fixed a few years ago?), snaggy desktop integration, because it's a pain to use at work on Windows, etc.

Re: Good Tools Are Invisible

#288

Post by bccdee »

zahlman wrote: post #256
jt2190 wrote: post #116

Earlier quoted context omitted.

> … discretionary friction ; designers or product folks adding features or complexity. This is far more precise. The article talks about this from the users side, how there is a class of user who enjoys learning all of these “extra” features, even though they ultimately provide less value than the core features. >> If people find vim, emacs, or whatever genuinely good and productive, I’m not going to criticize them f…

> a class of user who enjoys learning all of these “extra” features, even though they ultimately provide less value than the core features. I don't think this was actually established. The author may have a point about the UX of multiple cursors in Sublime, but comparing that to Vim macros is missing the point of the macro system — i.e. that you can create something that persists between editing sessions, and encapsu…

Yeah I think this is all coming from someone who never got good at vim.

Multi-cursors can be nice, but a sufficiently powerful implementation of that looks like helix or kakoune, and those are at least as complex as vim, if not more.

When you're good at vim, it is invisible. Once you're good at writing macros, you can do stuff which is impossible with Sublime-style multi cursors.

I assume those are situations where the author would have "just written a quick script," but vim macros are an interactive scripting language specifically designed to tersely express text transformations. Your script is never going to be quicker than that.

I'm not saying this as a vim partisan or anything. You could easily argue that vim over-optimizes and saves little time in the grand scheme—that's a fair critique. But it's strange to insist that complex tools are complex only for the sake of complexity. It's a weirdly conspiracist mindset.

Re: Good Tools Are Invisible

#289

Post by frollogaston »

iLemming wrote: post #278
frollogaston wrote: post #276

Earlier quoted context omitted.

Dunno, never had to do this. At most I might set PAGER=vim which means maybe something else is piping for me. If you're piping with vim then fine, but it's not a requirement to use it, unlike smaller utils that are begging to be piped.

> never had to do this is not a defensible argument (regardless of what you use), see the relevant comment here¹ the bigger point is to get more precise and utilitarian control over text which I already discussed here in this thread², piping in and out of your editor buffers sometimes comes very handy. ___ ¹ https://news.ycombinator.com/item?id=48876315 ² https://news.ycombinator.com/item?id=48869558

Kinda is, maybe I found better ways to avoid or deal with those scenarios.

Re: Good Tools Are Invisible

#290

Post by zahlman »

lionkor wrote: post #253
dtj1123 wrote: post #236

Earlier quoted context omitted.

I'm fully aware they're not the same thing, I'll not sure what gave you the impression I think they are. I agree that a badly written TUI is... badly written? Obviously I'm referring to well executed TUIs. For example, I regularly pipe the result of ls, grep or fd into Helix then use multicursor editing to set up a script. You simply can't do that with a GUI.

Those are not TUIs, or rather, when we say TUI we usually mean interactive UI in the terminal.

GP claims:

> I regularly pipe the result of ls, grep or fd into Helix

Helix is being identified as the TUI here. Terminal text editors are very much interactive.

Post reply on HN