> Young developers nowadays seem to mostly use dark backgrounds, which to me feels like a weird '70s throwback
Everything "young developers" nowadays do seem to me a weird '70s throwback - from the proliferation of the command line (as opposed to actually trying to create advanced GUI tools for people who know what they are doing, like a lot of developers did in the late 90s/early 2000s whereas today you mainly have dumbed down GNOME 3 lookalikes), to using tiling and lightweight window managers "for performance" on "low end computers" when those low end computers have massive supercomputer abilities compared to the computers that people used -again- in the 90s with UIs that did WAY more stuff despite their limited performance, to having crude dumb TUIs that look and behave worse than what you'd get in DOS in the 80s, etc.
You seem to be confused, developers work with text. What more can computing power bring to text? The only thing all that CPU and GPU power brought to the desktop is useless power wasting eye candy like beryl or whatever it's called now.
Plus, in this environmentally conscious time, isn't it nice that people want to do more with less? Why waste GPU cycles adding shadows and lens flares to text? I don't get it.
I like using tiling WM's (dwm and Awesome) because they organize windows for me and nothing is hidden in a bar. The concept of workspaces is much nicer than shuffling windows around a screen. I can quickly jump between workspaces and immediatly see my windows and contents. What more do I need? GPU rendering of windows? Why?
I along with many others enjoy doing more with less. My old i3 Thinkpad runs just fine. Plays youtube videos, streams music and edits text using OpenBSD. What more do I need? Why pointlessly throw more at a problem that doesn't need it?
This is exactly my reasoning — I love tools that do amazing things with minimal resources. I have a ten-year-old Thinkpad X300 running Debian with JWM. I mostly work in Emacs, terminal emulators, and a browser, so it performs very well indeed. Why would I want to spend a couple thousand dollars to have 3D titlebars on my terminal windows and run an OS that takes three times as long to start, when a $70 system does exactly what I need? It's not for everyone, sure — if I did a lot of video editing, or played games, it would be different — but it's more than sufficient for me, even with minor photo editing and CAD work.
If only I could find a car that adheres to the same principles!
No i am not confused, i'm perfectly aware of what i am seeing and writing, thank you.
> developers work with text. What more can computing power bring to text?
This is highly myopic, there is more to development tools that just source code and even visualization of source code and programs do benefit from being able to work with graphics. There is more to computing and programming than a 70s terminal.
And people use computers for more than programming.
> I like using tiling WM's (dwm and Awesome) because they organize windows for me and nothing is hidden in a bar. The concept of workspaces is much nicer than shuffling windows around a screen. I can quickly jump between workspaces and immediatly see my windows and contents.
Sure, although workspaces are available in overlapping window setups too. The rest you mention are just personal preferences, my comment weren't about liking tiling window managers over overlapping windows, it was about using those (and lightweight window managers - i included overlapping window managers too there) using them due to their resource use.
> What more do I need? GPU rendering of windows? Why?
I don't know but i have a feeling you'll just call irrelevant whatever i suggest.
But honestly...
> I along with many others enjoy doing more with less. My old i3 Thinkpad runs just fine. Plays youtube videos, streams music and edits text using OpenBSD. What more do I need? Why pointlessly throw more at a problem that doesn't need it?
...i think you totally missed the point of what i wrote. My point wasn't to throw more at a problem and especially not be wasteful about resources. Using and -especially- writing efficient software doesn't imply 70s terminal UIs.
A Pentium at 133MHz with 32MB of RAM, a machine that is a fraction of power of even the first Raspberry Pi, can run at comfortable performance an interface as rich as Windows 98. Even the lowest of the low performance laptops you can get your hands on today will have a ton more power, yet people treat it like it isn't anything more than a dumb terminal.
I don't really like the sound of my computer fan - so while it's nice to have a relatively good cpu, I still don't want it to be running flat-out all the time. Also, I'm not really sure what the point is of GUIs, other than looking flashy. I do a lot of 3D modeling, and I really don't like clicking around the menus whenever I have to. I figure that's just taste.
If you think that GUIs == Flashy, then i think you have a very narrow view of what GUIs are. Also a GUI does not have to be processing intensive and unless you have configured Linux to not use a graphical console and you are not using X or Wayland, you are already using a GUI. It is just that all your GUI does is draw text (which, btw, is among the most processing intensive things that a GUI can do).
GPU rendering of windows is likely more power-efficient than doing the same rendering work on the CPU.
Of course, once GPU rendering is possible, developers tend to fool themselves into thinking lots of animations and effects are a good idea, which then sucks up the efficiency gains again...
>You seem to be confused, developers work with text. What more can computing power bring to text? The only thing all that CPU and GPU power brought to the desktop is useless power wasting eye candy like beryl or whatever it's called now.
Yes, we work in text. Yes, text is quick easy and powerful. That does mean it is the right tool for every job.
Not everyone works somewhere taking down all your machines in some region for 30min because you typo'd -a when you meant -s when invoking some automation script is no big deal. Some of us work places where having normal operations carry the risk of that kind of thing isn't ok. GUIs when designed at least half-assedly make it significantly harder for people to enter dumb, dangerous or erroneous inputs while working at the same speed.
There's nothing preventing you from using a GUI to generate commands that will be passed as command line args and showing that to the user. In the few cases where you need to do something unsupported just invoke the command from the CLI.
Tossing up a quick web UI to streamline routine tasks while making users go out of their way to do non-routine or dangerous tasks is worthwhile at all but the smallest scale. Yes, it's quicker and easier to write a CLI tool but restricting the amount of rope just laying around to hang yourself with is part of operational maturity. With a GUI people at least have to go out of their way to find the rope.
Edit: Am I being down-voted because my opinion is unreasonable or just because it makes some people uncomfortable? At least tell me why I'm so wrong.
You're likely being downvoted because your comment is implying that risk of errors is a feature of GUI vs. CLI rather than about sound interface design.
You're conflating two entirely separate issues: Making it harder to trigger dangerous functionality vs. how the functionality is presented to a user. Nothing prevents hiding dangerous options behind extra steps in a CLI either.
I work mostly in text mode, but I also do use various simple GUI tools, and I half-way sympathise with what you want, though. What I've found is that in fact there are lots of nice little tools written to support minimal WMs or systems without desktop environments that are very useful in that respect. E.g. tools like rofi, dmenu and the like are great to wrap tiny GUIs around functionality that is hard to remember how to use correctly.
I work mostly in my own text-editor, and instead of writing a UI from scratch for it, I depend on the IPC support for the bspwm window manager to implement multiple windows/panes (the editor buffers are maintained in a server process, so I can have multiple views to the same buffer), and use rofi to bring up UI's. E.g. I have little scripts that bring up rofi with suitable input to select a server to ssh to, open a file in my editor, run a yarn/npm/make target, select a theme for my editor, switch buffers in my editors etc. Most of them are a handful of lines at most.
I'd love to see more tools like that, which makes building simple tool-specific GUIs for scripts easy.
I'm using Vim and i3 and not for performance, but simply because they are efficient and more flexible. Together with Vim browser plugins I can do almost everything on my PC without having to use the mouse, and with the right setup this can drastically decrease the input latency.
Modern PCs being insanely fast doesn't mean we have to use software that requires insanely fast computers.
Screen, tmux, vim, emacs, ncurses. None of these are 70s products. Nor do they optimize for 70s performance limitations.
They are modern terminal UIs. We pick terminal UIs because the terminal tends to expose a lot more features than a gui. This tendency is probably because it is easier to add features to a tui than to a gui.
Then there is a kind of self reinforcing effect where people like working within similar paradigms, and people get used to TUIs in general. This makes those people prefer making TUIs over GUIs even more. Incidentally, it is mostly developers who tend to need the more powerful features currently only offered in a TUI.
They are not 70s products but they look like 70s products. See my original comment about how those TUIs look and feel worse than programs you'd see in DOS despite having a lot more power and features available to them - even if you confine yourself to the basic colors (but many modern terminals also support -simple, yet usable- graphics, more colors and more characters).
> Then there is a kind of self reinforcing effect where people like working within similar paradigms, and people get used to TUIs in general.
Yes, it is basically a matter of fashion and what baffles me is that fashion.
I mean, even if you consider that terminal-based applications are great, why limit yourself to what a beefed up VT100 could do? Why when typing "ls" not also have a tiny folder icon near the directories (you are already going into the hassle of adding colors anyway, a little icon would make it more obvious which are folders and which are files when you are looking at a huge list), why not having a command akin to "cat" that can decode and display image files right in the terminal, why not have an over-time graph in "perf"'s realtime TUI mode, Emacs already supports different font sizes when running as a GUI program, why not have this in terminal mode too, Clang's static analyzer can show you data flow-based errors, why not have graphical arrows superimposed over your syntax highlighted code when you run it from the terminal (Xcode already does that but it is a GUI), etc.
These are just some examples from the top of my head, i'm sure i can come up with even more.
I think by using only text-based UIs people get used to text-based UIs and all they can imagine is within the limitations of text-based UIs.
Lots of terminals do support graphics in various ways, e.g. formats like Sixel (bitmap graphics), ReGIS (vector graphics), and others. Several have experimented with folder icons. Many support e.g. URL matching, and some support outright hyperlinks.
My setup does use a Sixel enabled (and ReGIS but the ReGIS support is poor) Xterm.
Here's the thing:
Years of experience is that the gain is very much marginal. I really want to do more related to this, and it can sometimes be useful. But unless you're sending images over an ssh connection, Sixel output to xterm is no easier than opening another window most of the time. My ls replacement locally already shows symbols and uses colours; the benefit of going to images instead of unicode characters is minimal. Drawing lines instead of using Unicode box drawing is similarly such a marginal improvement that for most things it doesn't offer much.
There are things where it can be nice, such as e.g. being able to plot a histogram from output from shell tools without opening a separate window (and making it work over an ssh connection), but even then you can mostly get there with unicode characters too, and then you don't have to worry about whether or not you'll need to use those tools from somewhere without a Sixel or ReGIS enabled terminal.
And there's the rub: these gains in functionality are so marginal that the benefit is very easily lost when you often work on multiple machines, because suddenly you have to distribute them to all the machines you work on, or juggle between multiple sets of tools.
Yes, terminals do support graphics like they do support applications that look at last as good as applications you'd find on DOS (if not better), my point is that the programmers who make those applications do not take advantage of those.
And my point is that a large part of the reason for that is that experience with the terminals that originally supported this functionality, and modern attempts to resurrect it, is that even when you do have programs that takes advantage, the benefit is smaller than you might think.
I still want to do more with it. I grew up with an Amiga where the terminal was a system service that could be trivially embedded in a window and co-mingled with gui elements. I still think parts of that design are ahead of modern gui's. But it's also an ecosystem thing. It's more important to have software that works together than to get those gains that individually are quite minor. You first get the full benefits when things start coalescing into a greater whole.
> Why when typing "ls" not also have a tiny folder icon near the directories
This is already reality. Tools like lsd do that by default.
> I think by using only text-based UIs people get used to text-based UIs and all they can imagine is within the limitations of text-based UIs.
No. One of the main reasons I like this "limited" UI is because it also means less clutter. No popups, no stupid notifications or animations, no useless and seemingly infinite menus. Just relevant information and nothing else. I can imagine a UI without these limits, I've used it for decades, and now I'm glad I can often stay away from it. If there wasn't a huge problem with horrible overloaded UIs we wouldn't have plugins for blocking ads and scripts on websites or distraction-free modes in text editors.
I'm not against displaying simple graphics in the terminal(e.g. like ranger does), but there's a point where a decrease in limitations only means an increase in eye candy.
> They are not 70s products but they look like 70s products
I'm not sure how you could have a TUI that didn't look old. For serious applications, you have to build TUIs assuming the worst - that the user has no colors or special keys. Sure, some terminals can display bitmapped images with 24-bit color, but you can't depend on that, especially for anything running over SSH or within Tmux, screen, emacs, (neo)vim, or some combination of these. These can create some very obscure bugs related to colors and keybindings, so you can't assume every key will work as expected or that your users will have color at all (I disable Vim syntax highlighting over SSH because it tends to demolish its performance, for example). This is why many TUIs are 16-color and use just ASCII characters - you don't know if the user can display emojis or if it'll show up as a garbled mess.
GUI applications (including text-based ones like gVim and emacs) have a lot more flexibility because they can control more than they can in a terminal and can guarantee 8- or 24-bit color instead of having to hope for 16-color support.
> Why when typing "ls" not also have a tiny folder icon near the directories (you are already going into the hassle of adding colors anyway, a little icon would make it more obvious which are folders and which are files when you are looking at a huge list)
That would probably break a lot of scripts. I just alias "l" to "ls -l" so I can see the permissions (which has a "d" to indicate directories).
> For serious applications, you have to build TUIs assuming the worst - that the user has no colors or special keys.
Realistically, what are the chances of this happening nowadays and how worth is it supporting such users?
> That would probably break a lot of scripts.
If an icon would break scripts, so would having colors, but it doesn't since ls knows when it outputs to a terminal or to a pipe and adjusts the output accordingly. But this misses the point, it could be another commands like vls (visual ls) or whatever, the point is the ability to use more than ASCII text.
> I just alias "l" to "ls -l" so I can see the permissions (which has a "d" to indicate directories).
An icon is more distinguishable from a single letter and using the -l view would not take advantage of any horizontal space you have.
When gnome 3 came out I had to find something else to use, so I chose one of those "light weight tiling window managers" since if I was going to be setting up something custom anyway I might as well do some research on it.
I've ~yelled at~ talked to a bunch of gnome developers trying to figure out exactly what's going on. I think that they're making the weird UI decisions in the name of "inclusiveness". They believe that simpler apps, and a standard unified ecosystem, makes things easier for marginalized groups to adopt free-software. All their weird technical decisions ultimately seem to be justified by making things easier for marginalized groups.
The Unix tools don't work on guis. Piping between applications on the command line is still faster and simpler to hack together than a real solution. I don't feel the need for anything more because the desktop is pretty much dead and so are the metaphors it used. We might as well be complaint that the devs today aren't designing a touch based interface to get real work done on a phone. Me and my Bluetooth keyboard on termux are doing well enough thank you very much.
This is more of an accident of history, there's no reason you can't have pipe friendly collection of graphical tools, dmenu is one simple example: https://wiki.archlinux.org/index.php/Dmenu
Who are you addressing this to, end-users or UI designers? The debate seemed to start off asking "why do people prefer text UIs" and now seems to have morphed into "why don't OS vendors innovate in text UIs more".
I don't know the answer to that, but it's not really relevant to the initial debate; text UIs, for all their lack of innovation, are still dramatically better than GUIs for many use cases, which is why I use them.
I do not want to go off and spend years designing and implementing the theoretically perfect OS and toolchain before I can do other work, I just want to use the best of what exists today.
My original comment was targeted to both users and developers, but obviously the "make better tools" is only targeted to the subset that can make those better tools.
Other than using json there's nothing to improve on for the type of work I do. With jq and a few self written small programs in C I get on par performance with 'better' tools that have teams of hundreds working on them.
On my case, I've switched to tiling window managers because it streamlined my work and made me a lot more efficient. It has nothing to do with "performance" in the computing sense.
I've tried to use the existing "containers" systems on regular desktops and they simply sucked. Not even close to what I get on i3.
This idea of using the mouse to click on everything you need to do is something I cannot get around. Creating advanced GUI tools for "people who know what they are doing" sounds counter-intuitive to me. If you know what you are doing, you can use the damn command line.
GUIs are normally built with less features and/or dumbed down versions for the average user, not the other way around. I suppose if we forced ourselves to build better GUIs that were super flexible, this wouldn't be true. But the reality of today (or ever?) is that normally if you know what you're doing, you're using a CLI and not a GUI.
Yes, this is how things are nowadays and what i refer to in my message above: developers basically gave up trying to make more advanced UIs and regressed to 70s-styled terminals.
It's not regression. It's progression. Power users are more efficient and proficient on what you (incorrectly) refer to as 70s-styled terminals. It took us a while to get there. We went down the wrong path with fancy GUIs in the 90s, 00s. Things like not needing a mouse, being able to freely tie programs/commands together, being able to script every aspect of your workflow,... these are all big wins for power users. If there is an easy way to achieve the same flexibility with GUIs, then it hasn't been discovered yet.
The best of both worlds is having a REPL, just like the Xerox PARC and ETHZ workstations did.
My first startup was an heavy Tcl shop, thanks to it I learned never again to depend on languages without support for JIT/AOT on their canonical implementations.
Because reflowing 1000 words is a lot simpler that designing a general method for conveying your message on any given aspect ratio, resolution and size.
Because text is a lot more portable across platforms.
Because interacting with text is a lot easier to automate. And extracting information from text automatically is easy whilst extracting it automatically from a picture is very difficult.
GUIs are great for discoverability, and complex long ineractive sessions. But they also have downsides.
Why use a picture when you can tell the computer what to do, such as going out to the café while the computer is either number crunching/photo editing with ImageMagick by itself?
The mouse is the least ergonomic input device. I have a trackball which is mildly better. Until someone develops a pointing device that doesn't cause rsi I will stick to tiling wms and terminals.
I am also an order of magnitude faster at my job than my colleagues stuck in gui land,pecking away at their IDEs. Not to mention I have a greater command of the languages we use because I am not relying on an AI to guess syntax for me.
Avoid tiling, it sucks. Switch to a keyboard drivable WM such as CWM. You can use keybindings to resize, tag, delete windows without botching the aspect ractio of your browser/80x25 TUI terminal.
And it has an inline window-search menu which is really convenient, it can autocomplete window names too :D
"xterm -T yourtitle -e nvi", then in my case I press super+a, I type "you<tab>", I press "intro", and my xterm raises up.
No stupid tiling, no window resizing, no borked aspect ratio.
To unclutter my screen, that's what are tags (almost like virtual desktops) for.
I will consider switching away from a tiling wm the day I have enough screen real estate. Until then, I want to use as much screen space as possible on actual window contents. I really could not care less about the aspect ratio of my terminal windows - the applications I use know perfectly well how to deal with resized windows.
> I want to use as much screen space as possible on actual window contents.
I was like you, until I began to use a max 2-3 open per tag/workspace. The clutter ended.
Tiling is useless under Unix environments where virtual desktops are a norm since ~1989. They may worked great under DOS and pre Windows 3.1 where few things are open, not under a powerful multi virtual-display based environment with several terminals running at once.
I do have 2-3 open on most of my workspaces. I have 10 workspaces. It's only just about sufficient.
I've used virtual desktops since my Amiga days in the mid 80's - they are not a replacement for wasting as little of what space is actually visible at any given time.
Aside PowerShell already mentioned before, Windows had system-wide scripting since Windows 98 (some parts since Win95) with windows automation and active scripting that allowed any application to expose COM objects and interfaces for manipulation by other applications either directly (via COM calls) or via active scripting, which provided pluggable scripting languages so that you could use any scripting language - JScript and VBScript provided by default - to access any compatible COM server. In addition applications could also expose and host reusable controls (initially known as OLE controls, later rebranded as ActiveX controls) and some applications (such as Office and Visual Basic) were made explicitly to allow composing applications out of such reusable controls (Visual Basic since version 4 was basically a scripting environment for COM).
The two main issues with the above was that because it was made to be interoperable with any native language that had support for functions and structs, it was complex to do it right and only expensive (meaning, difficult to acquire for many developers) tools could help you with that. And, really, another issue was that most developers simply didn't appreciate the flexibility and composability it offered (they still don't, see how no Linux environment provides even something like Windows 3.1's OLE, let alone something like COM).
Yeah, that gave us Macro virii, IE6 hell and well, the API on Windows was utterly verbose and non-docummented.
Poweful, but as it was too obscure for the end user/programmer compared to the in-place source of Nixen+man pages, guess which platform was both free and easy to code.
VC++ was expensive too, BTW.
On COM/OLE, on UNIX no one cared because by design you could embed whatever shit you wanted, from video players to window manager modules. And TCL was amazing.
Windows has been embracing composable shell tools, scripting and automation for over a decade with PowerShell; Microsoft Exchange management was powershell in 2010 including the GUI which also generated the cli code in case you wanted to automate what you just clicked through.
PowerShell syntax is too verbose (That's why I hate Java and .Net). Also, UNIX' composability and parallel execution (no pun intended) wins over objects.
Everything "young developers" nowadays do seem to me a weird '70s throwback - from the proliferation of the command line (as opposed to actually trying to create advanced GUI tools for people who know what they are doing, like a lot of developers did in the late 90s/early 2000s whereas today you mainly have dumbed down GNOME 3 lookalikes), to using tiling and lightweight window managers "for performance" on "low end computers" when those low end computers have massive supercomputer abilities compared to the computers that people used -again- in the 90s with UIs that did WAY more stuff despite their limited performance, to having crude dumb TUIs that look and behave worse than what you'd get in DOS in the 80s, etc.