←back to thread

538 points todsacerdoti | 2 comments | | HN request time: 0.633s | source
Show context
pjmlp ◴[] No.44363232[source]
As someone that was happy that I could finally afford owning computers with a graphics display on them, this going back to the terminal doesn't stop surprising me.

We still do horses, but hardly anyone is favouring them for travelling around the continent delivering mail.

Kudos to the people that would rather experience that, I guess.

replies(12): >>44363308 #>>44363330 #>>44363352 #>>44363403 #>>44363450 #>>44363648 #>>44363674 #>>44364156 #>>44364655 #>>44364828 #>>44365517 #>>44365685 #
ur-whale ◴[] No.44363674[source]
> We still do horses, but hardly anyone is favouring them for travelling around the continent delivering mail.

Except that if you've ever seen someone who truly knows how to use a terminal, you'd be surprised how many times faster he can work than with any other UI-based workflow.

This may change with AI, but so far I'm not holding my breath.

replies(2): >>44363705 #>>44364528 #
delta_p_delta_x ◴[] No.44364528[source]
Literally twenty minutes ago, I had to submit several hospital invoices for insurance claims. The website, despite claiming it'd accept PDFs, didn't consider the PDFs I uploaded valid, but somehow PNGs worked. My first thought was 'let's script the conversion', but then I realised there were only six PDFs, so I opened Acrobat, and used keyboard navigation to run through the menus to export all PDFs to PNGs. Done in two minutes flat.

Had I chosen to script it, I would probably still be hunting for the CLI to convert PDFs to PNGs. Sometimes, the trade-off is not so clear.

replies(2): >>44365251 #>>44365281 #
ur-whale ◴[] No.44365251[source]
>the trade-off is not so clear.

Assuming very basic knowledge of CLI on Linux

    for i in *.pdf; do convert "$i" "$i".png; done
10 seconds flat

If you've never heard of convert (part of imagemagick) then:

    open chatgpt/gemini/claude/whatever, enter prompt:

    linux cli tool to convert pdf to png
Adds 30sec tops

Thank you for making my point for me.

replies(1): >>44387193 #
delta_p_delta_x ◴[] No.44387193[source]
So I, running Windows, using PowerShell, already knowing CUA shortcuts, generally familiar with Acrobat and its features, having to eventually use the mouse and keyboard anyway to navigate a JS-heavy insurance website, additionally have to:

1. Install sh/bash to get `for`, or convert your 'handy one liner' to PowerShell, and verify it works

2. Install ImageMagick, then ask an LLM to tell me what to do

2.5 And somehow LLMs don't present `convert`, but `pdftoppm`, or worse, both, and give me one giant essay, without my pre-configuring the system prompt to be concise and not overly wordy and avoid meta-sentences like 'if you want more help let me know';

3. Then navigate to my website anyway, and upload everything.

So no, point not made for you. With my existing environment and existing knowledge, it took me two minutes to get the work done. Even the slightest search would have brought me above that measure. There is a local minimum for a certain n at which discoverable GUIs absolutely excel over CLIs.

replies(1): >>44387430 #
1. ur-whale ◴[] No.44387430[source]
> So I, running Windows, using PowerShell

Well, what can I say other than people don't usually get in races with lead weights tied to their ankles.

replies(1): >>44387625 #
2. delta_p_delta_x ◴[] No.44387625[source]
It's not a race; it is optimising the process for the input size, one's existing knowledge, and context-switch duration from an existing environment. If I had fifty PDFs, I'd look at scripting the result immediately. I had six, and I had Acrobat. I chose the GUI option, and it got me a decent result quickly enough.

A code analogy: it's a bit like how O(n^2) sort algorithms are the fastest for small n, and how most library sorts choose a different algorithm for different `n`. This is what I meant in my initial comment when I said

> Sometimes, the trade-off is not so clear.