On Wednesday, 30 September 2015 at 01:59:38 UTC, Jonathan M Davis
wrote:
On Wednesday, 30 September 2015 at 00:20:46 UTC, H. S. Teoh
wrote:
On Tue, Sep 29, 2015 at 04:50:37PM -0700, Walter Bright via
Digitalmars-d wrote:
Really, what's the case for not supporting this? Am I really
a unique snowflake?
Nope, you're just too smart to use a GUI. ;-)
Issues like these were part of what convinced me that the
so-called desktop metaphor was bunk and that the current
infatuation with GUIs is a case of emperor's clothes, and
drove me to embrace the *nix shell.
GUIs work quite well for certain types of applications -
especially those that are very visual (e.g. Photoshop). And in
general, if they're done correctly, they allow you to do a
certain set of operations efficiently and easily, but by their
very nature, they don't tend to be very flexible, and when you
do try and make them flexible, they tend to get very
complicated, very fast.
Contrast that with Unix utilities, which are usually designed
to do one job and do it well and then interoperate with other
such utilities cleanly. Because each one is simple, they work
well, and because they're composable, you have a _lot_ more
flexibility than you get with a GUI. So, in general, the unix
philosophy just ends up working better. But it _does_ require a
certain kind of thinking from the user that tends to go well
with programmers but not so well with the average joe, and even
with that in mind, there _are_ applications that work better as
GUIs.
Excellent unfolding of this point, and one I have been pondering
for my own use case. I would like to be able to explore data
interactively using various building blocks written in D that I
can strap together quickly. User interfaces matter so much for
things you do everyday, yet often people are more concerned with
making it shiny for the marketing guys than productive for
serious users - especially so for relative monopolies.
It's interesting to see how different applications tackle this
problem. It doesn't necessarily need to be either GUI or command
line. For example, the Bloomberg terminal is kind of a
combination (more old-school GUI than not, and the GUI bit is the
one I like least). The ipython/Jupyter notebook is another kind
- that's great for writing intermediate size chunks of code but
not so much for use as a shell. So another possibility is the
qtconsole style. (Maybe R and Julia, but I am less familiar with
those). I think in both Jupyter and qtconsole you can have
graphical widgets (certainly in Jupyter).
Adam Ruppe's terminal is quite an interesting approach. as you
can display images inline within the terminal window, and not
hard to make them interactive. Possibly a shell with graphics
and some kind of light scripting language like Lua can be the
best of both worlds, in particular in relation to the
composability aspect.
In Bloomberg if I want to see which bonds are deliverable for the
front month gilt future, I can type "G A[F9]DLV[ENTER]" and see
an editable analysis window pop up - not quite a commandline, but
shortcuts on steroids. It's easy to replicate this kind of
shortcut in a terminal (including prompts/helptext etc) whilst
still having the ability to do more powerful things using the
commandline without context switching.
for example findticker --macro --confidence/consumer GBP | less
(not something that will go quickly in Bloomberg because GUI).
or findticker -- macro --confidence/consumer OECD | chart -s 2009
-f monthly
(find all OECD consumer confidence numbers and plot them since
2009)
Laeeth.
