Hacker News Reader

Comment by Moru | Hacker News Reader

But with the terminal you still have to learn commands, it's not as discoverable as the windows 95 environment. There you could do things as a noob by just looking around and after a while you could do things without even thinking. Every windows version after that has broken that flow in some way. In Linux I keep forgetting what file to edit to get what I want. I need to look up location and syntax for most things every time I want to do something.

View on HN

I like to describe the shell and commands as a big dashboard with many levers and indicators compared to a much simpler one with just a small bunch of ON-OFF switches. They're indeed complicated, until the day you need to change something that isn't on the simple panel, or isn't a simple ON-OFF choice, because every operating system is complicated; you can hide some of its complexity behind a graphical interface, but you always lose something in the process because you can easily have a command with 100 options but you can't put 100 buttons on a screen. It simply doesn't scale. So the next question is "how do we put a complicated system under control of a simpler graphical interface?" We make assumptions of course (read: we write code that makes assumptions), and there is where bugs arise or more complexity is created, because machines (still) aren't good as humans at doing some things. As an example, very complex string operations can be performed using sed, awk and the usual shell command with regular expessions, where on Windows for years (I have no experience with its new shells) many people would have to load Office, import the text, write a macro, and export back the text. The difference being that Office would likely need two orders of magnitude more computing power, memory and storage.

> but you can't put 100 buttons on a screen. It simply doesn't scale.

You can scroll, use pages, tabs, nested menus, guided wizards, Chrome or VS code style searchable settings lists, buttons which appear or disappear dynamically when necessary.

> where on Windows for years (I have no experience with its new shells) many people would have to load Office, import the text, write a macro, and export back the text.

If you can assume office, why can’t you assume gvim or any other text editor with a gui? And why is text editing your yardstick? At least you can do that with a gui somehow, image processing you can’t do with a cli - yes you can write the code for ffmpeg or graphviz but you can’t see the result without a graphic interface.

I agree with you that an application needs discoverability. Like a text processor for a writer or a photo editing software for a photographer. It should make sense for a particular domain, requiring only minimal training for the medium. But we can't abstract away the notion of computers. An analogy is car. Driving a car only require a minimal interface. Racing with one, however, requires a lot more knowledge. Repairing a car is where knowing the internals is the minimum. Different needs, different levels of knowledge. Most people would be happy with the iPad if only the applications were a tad more useful (File sharing is aweful). But some people do "general computing" and graphical interfaces usually fail in some way or another (especially with automation).

With help of codeLLM or shellLLM, that is no problem any more

Reply on news.ycombinator.com