You see this shit SO much more often than you would think. And the infuriating thing is, it seems to be most common among programs that are INCREDIBLY complex and sophisticated.

It’ll be like this:

“What does my program do? Glad you asked. It simulates stress patterns in glass and ceramics, after they come out of a kiln. You can specify any melting temperature, adjust the composition of elements in the glass, and the ambient temperature of the cooling and tempering stages.”

“Wow, can you show me how it works?”

“Sure! <opens a command line and starts typing commands>”

“O-oh. Do you have any plans to add a graphical user interface?”

“HAHAHAHAHHA, no. That’s never happening. And here I thought you were serious about using advanced software, and being an intelligent person.”

Obviously, that last part is just kinda implied. But sometimes, when users request a GUI, the goddamn developer will kinda get in their face, like that.

They always fall back on the position of “well, I developed this shit for free, for your ungrateful ass. So you can build your own fucking GUI.”

But the thing about that is…no. And fuck you. I shouldn’t have to be two-thirds of a fucking developer, in order to use the fucking software.

If you can figure out how to simulate molecules, or draw 3D stereograms, or translate hieroglyphics, or any other RIDICULOUSLY COMPLICATED SHIT, making a graphical user interface should be nothing to you. You should be able to do it in a fucking afternoon.

IT DEFINITELY SHOULD BE THE EASY PART, FOR YOU.

All the rest of us, who aren’t programmers? We envy programmers, and their ability to really connect with computers, on that deep logic level.

If we could do that shit, we would. But a lot of us have tried, and we realize it’s not a good use of our time. We can do cool stuff with software, but it’s just not ever going to be worthwhile for us to struggle through the act of creating software.

Also, I hasten to add that I have put in my time, using command line interfaces. I used DOS, I used BBS systems, I have used modern command-line-only programs. I know how to do it, but I DON’T WANT TO.

I don’t want to have to memorize commands. I don’t consider a GUI workflow to be some kind of weird luxury. It has been a basic part of modern software, for around 40 years at this point. Literally get with the program, guys.

If you’re serious about making software, get your shit together and implement a fucking GUI from the very first release. Nobody ought to be taking you seriously, if you refuse.

  • Chill Dude 69@lemmynsfw.com
    cake
    OP
    link
    fedilink
    arrow-up
    1
    arrow-down
    1
    ·
    9 months ago

    I mentioned VisiCalc to a couple of people, in this discussion, and I think it REALLY needs to be remembered more often, and more clearly.

    I keep seeing a lot of people replying to various parts of this discussion, with varying degrees of this opinion:

    “Anything you can do with a GUI can be done without a GUI. You basically just THINK you need a GUI, because you’re a lazy non-software person. You just need to get used to using CLI, and when you do, you’ll thank me, because you’ll be able to do even more powerful things than you ever could, with your GUI crutch.”

    Well, spreadsheets blow that entire argument out of the water, instantly.

    The whole thing about spreadsheets is the fact that they are a GUI. The original VisiCalc spreadsheet application BARELY had a GUI. It was all text characters. It was barely running in realtime. But it was a realtime GUI, and that was the entire reason that it was useful.

    Note that you could make a command-line-only spreadsheet program. As in, an entirely hidden spreadsheet, where you use commands to define the fields, enter the data, and then use other commands to do operations and query for the results. But that’s entirely destroying the whole point of the spreadsheet, as a tool. With VisiCalc (and all modern spreadsheet programs), you can see all the fields at once, change them in any order, and watch as any other relevant fields are affected by the different numbers.

    As many people have said about the spreadsheet revolution, it allowed people to “play around with the numbers.” For most users, that was what elevated the microcomputer from a mere calculator to a game-changing, paradigm-shifting, universally necessary tool, for anyone who did any kind of business.

    Before VisiCalc, you might as well just use a digital calculator, to help you with your business stuff. Just using command-line programs to do calculations wasn’t really any faster than a desktop calculator. And those desktop calculators usually had hard-copy printers built into them, so that you wouldn’t ever have to re-list the queries you’d made, to refresh your memory.

    But, again, the realtime GUI spreadsheet blasted all that apart, and gave users life-altering tools. It wasn’t just a matter of “oh, look. We dumbed down the interface, so that stupid Bob the Business Major can finally use software.” It was a real step beyond what command-line tools can do.

    Now, think about my example of a molecular simulation program for melting, cooling, and tempering ceramics. Isn’t that process even more complex than doing sum and division operations on some dollar values, rounded to two digits after the zero? Doesn’t it logically follow that you’d want a GUI for a molecular simulation tool, so that you could PLAY AROUND WITH THE NUMBERS, in the same way that you would, with your business expense sheets?

    That’s the whole point of the software doing simulations, right? On the one level, it’s simply easier to poke around at finite-state machines that model known physical and chemical properties than it is to do a bunch of experiments in a real kiln. That’s the first stage of why simulation is good for progress. But it really does go beyond that. I would argue that a GUI in a simulation lets you see things from angles that you would never have thought of, before you started tinkering.

    If you have to think about how you’re going to query the system, on a command line, then read out the data afterward, you’re going to run up against the limitations of the human imagination. Some users will think of every query they ought to make, without any prompting, and with less trial and error. Others will never think of certain aspects of the simulation, unless and until they can SEE the parameters laid out in front of them, in a graphical, preferably realtime fashion.

    Obviously, not everything can be realtime. But graphical interfaces always allow better viewing of simultaneous and parallel functions.

    It’s not just a matter of “we’ll throw some of these non-techie users a bone, and make this stuff easier for their lazy asses.” There ARE fundamental advantages to a GUI, which truly to go beyond simple “user friendliness.” Succinctly, a GUI user is not the opposite of a power user.