Pathing in the D ecosystem is generally broken (at least on windows)

[Laeeth Isharc via Digitalmars-d]

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.