Which is fantastic endorsement. GUIs and the Web may be nice for mucking about - but when I work - I work on the command line (or in emacs). All I truly care about is daemons and command line interfaces.
Of course - my daemons and command line interfaces have to produce pretty output, for people who care about other things. But those people are not me.
So I installed Plan 9 from User Space[1] last night - largely on this recommendation :)
I feel like GUIs these days cater too much to novice users. Obviously the old-school terminal/no-graphics style is pretty dated, but I have yet to see a nicely integrated solution with the advantages of GUIs and the power of the cli.
So after your first comment I was wondering what GUI gives you as far as tools in an IDE that you couldn't have with curses style terminal-based interface.
Emacs (and vi) do a wide assortment of refactorings, auto-completions, multipaned outputs, large scale cut and pastes etc. I couldn't think of anything that actually needed graphics. Given that i couldn't think of any reason why an IDE needed to be a GUI.
That is to say I can see people preferring the look, or the use of a pointing device, but I couldn't figure out any coding features that where actually GUI-only. You have any I couldn't think of?
Code navigation, able to represent visually references between modules, packages, binary files. Quite handy to navigate across large code bases, typical in enterprise environments.
Another nice feature is the ability to see graphical representations of data structures. Specially handy for list and tree based structures.
Have you also used Acme (non-trivially)? The UI makes heavy use of text (the whole thing being a text processing environment after all) but the graphical aspect is highly significant, and most of the (fairly complex) interaction is via mouse.
The Plan 9 userspace excels at tying text-using utils, but the traditional Unix CLI is not the means by which you tie them. Even the terminal is quite far removed from a typical command line.
Acme is based on how the whole Native Oberon OS works, which provides a much better UI experience using the same principles, specially the last version (System 3).
That is nothing new, it is how Native Oberon works (1987), which is based on Smaltalk (1972) works.
In Native Oberon, every module can export functions as commands that are mouse callable in the UI and take input from mouse selections, which can even be UI objects (gadgets).
Most of the mouse/keyboard interactions in Rio were already available in Native Oberon.
