Hacker News Reader

Comment by pipo234 | Hacker News Reader

Creating a GUI to cater for "normal people" has merits. But GUIs, and especially GUI-only apps come at a cost too.

Using the Unix philosophy to combine text based tools does not translated to GUIs. How about test automation?

Back in the day when I was still forced to develop software on Windows or Mac OS I wasted so much time maintaining brittle click & even snoop-based integration using kludgy tools like selenium and add-hoc click-the-freaking-button.exe just because the app originally happened to be developed natively in Java, Flash, HTML5+ajax by some rockstar, 10x coder without seatbelts.

View on HN

Also even when just using Windows, it's frustrating how the ecosystem convention seems to be to launch a heavy program with an idiosyncratic GUI to do any simple file -> file transformation. And half the time these trivial apps are proprietary free/shareware nagging you to "upgrade" for features like "not arbitrarily restricted to 10 files". Luckily a lot of the command line tools I use on Linux will run on Windows, it's just that few people bother due to an irrational fear of the command line

Or how about all those windows 99% CLI programs that once in a silver moon decide to bother the user with a pop-up "Are you sure Y/N?". You find these on billboard, kiosks, payment terminals, ATMs.

Or try running a simple Java tool on headless Windows using Jenkins agent or cygwin SSH and you'll discover how horribly bad relying on a GUI can be. Or: how about automatically launching a MacOS VM on VMWare and setting up a VPN tunnel after a restart power outage without a mouse, keyboard and display. Should work in theory, but in practice never gets beyond most of the time.

I mean everything has a cost but quadrupling the number of users is the benefit.

There’s no reason why an app can’t work as well either via command line or via GUI. The whole point of architecturing your software is so you don’t write something kludgy.

Reply on news.ycombinator.com