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! "
"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.
Congrats on the true unpopular opinion lol.
I'll add one thing that I don't think has been said, adding gui adds a lot to the dependencies and complexity of maintaining a program. Keeping it in the cli keeps the size of the program down, and ensures it will work longer and on more devices since it's dependent on less libraries that could change.
Because of that, if a cli program gets a gui it's usually a separate project, like how yt-dlp has front-ends like this.
I asked another person this, but I'll ask you, too:
Why is all of this SO INCREDIBLY DIFFERENT when it's a game being developed, instead of a program that does non-game stuff?
When you go to learn game development, every student is being taught to use an engine to manipulate graphical elements in, like, the second hour of study. Why not use engines (even the same game engines) for non-game applications?
Is there some real reason not to do this, especially for small projects? Am I missing something fundamental?
Front end and back end development are two very different things. I can write extremely complex software, but I couldn't design or code a GUI to save my life.
They're two very different skill sets.
I suppose there really does need to be a renaissance of people trying to contribute on the frontend side.
I do feel some real motivation to get my shit together, learn Godot, and start shoving small open-source projects into it. I could make a difference.
Exactly, be the change you want to see in the world. You've identified a problem that you feel strongly about, just like the developers of the esoteric software. If GUI development is something you can get into, go for it (plus, good front end devs make a lot of money).
Agreed.
I am still curious, as to why this hasn't been a solution, already.
For that matter, why isn't there any kind of industry standard "non game engine" that caters to productivity, academic, and specialized applications, in the way I'm describing?
Games are already doing a lot of complex things, and pretty much all games are inherited graphical (other than text adventures I guess).
And a game engine is useful since it helps you do a lot, but it's also a huge dependency with a lot of moving parts. This can be a problem even for games, but games do so many things that having an engine often outweighs the downsides.
Using ytdlp as an example again, that just has to connect to the Internet, and write to a file. Using a game engine for that would be major overkill and make the project way bigger then it has to be, as well as increasing the barrier to entry for developers who want to contribute. Python can do all those things but is lighter, smaller, more flexible, and has a much larger userbase.
But what if that makes the difference between users being able to actually use the software, versus...just literally not using it?
Keep in mind that I'm talking about end-user software, from the very start of the conversation. Not backend-only stuff, not tools that are only ever going to be used for batch process stuff. I'm talking about stuff like my example of a simulation program for glass and ceramic casting.
Wouldn't it make absolutely perfect sense to use a game engine for something like that? The user won't give a fuck if it takes 2 gigs of disk space, and has a loading screen on startup. They are going to be spending real hours of time, using the application to generate actionable information.
The Python solution that would be lighter, smaller, and more flexible isn't any good if nobody actually implements it, right? And, from where I'm sitting, it seems like the version that uses Godot or Unity would be so much more actionable.