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

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 30 September 2015 at 04:48:35 UTC, H. S. Teoh wrote:
> On Wed, Sep 30, 2015 at 01:59:36AM +0000, Jonathan M Davis via 
> Digitalmars-d wrote:
> I know the commandline scares away your average joe. That's the 
> kind of audience GUIs are catered to, which is understandable. 
> What gets annoying is when you're *forced* to use GUI even if 
> you're not the average joe. Many tasks in Windows simply cannot 
> be done without clicking through the GUI. You have no choice in 
> the matter. Where it get ugly is when the GUIs in question have 
> issues, like non-resizeability or non-copyability where there's 
> no *technical* reason why it cannot be done. That's when I 
> start wishing it was Linux where I can just fire up a text 
> editor and edit system config files directly instead of getting 
> an aneurysm from clicking the rodent trying to coax it to do 
> what I want.

Yeah. A big problem with mobile platforms, Windows, and Mac OS X 
is that they all tend to target the average joe and don't 
necessarily give the power users good tools (I suspect that Mac 
OS X does the best out of those given its BSD underpinnings, but 
I haven't used it, so I don't know). Linux and the BSDs do a 
_far_ better job - probably because they're pretty much written 
by geeks for geeks. They're not trying to dumb everything down. I 
hate dealing with mobile precisely because they're trying to hide 
the fact that it's a computer and are trying to dumb the whole 
thing down for the average joe. Windows isn't as bad, but even 
when it does a fairly good job, it's still catering to folks who 
are scared of the command line. And some of the changes that 
they've made over time have the same problems as the mobile OSes 
where they're basically trying to hide a lot of stuff from the 
user - especially stuff related to the filesystem.

>> But it's that simplicity and composability that gives us a lot 
>> of the power that we have with ranges, and I think that you 
>> can see some comparisons between a range-based approach and 
>> what you'd typically get in many other languages (particularly 
>> when OO is involved), where you often end up with objects that 
>> have everything and the kitchen sink in them, which can be 
>> quite useful and in some cases, easier to use, but ultimately 
>> it's a lot less flexible and harder to maintain.
> [...]
>
> The infamous god-object? I thought that was an antipattern...

It doesn't usually go _that_ far, but when using OO, it's still 
pretty common to put everything on the class, and very little is 
generic. So, if functionality gets added, it gets added to the 
class that the programmer wants to use it with at the time. It 
actually tends to make it easier to find functionality, because 
it's grouped with what it's used with and documented with it, but 
it really isn't reusable. So, even if a class isn't so 
complicated that it's a god-object, it can still have way more 
functionality on it than necessarily makes sense, especially if 
you start thinking about generic programming and being able to 
reuse functionality.

Another example would be frameworks vs libraries / components. 
With a framework, the programmer that wrote it provides most of 
the functionality, and you override and/or fill-in pieces of it 
for your particular application. It saves you a lot of time and 
effort, because you don't have to code it all up yourself, and 
often, you don't even have to understand that much about how any 
of it works, because it's doing so much for you. However, a 
framework generally isn't very flexible (or if it is, it gets 
_very_ complicated, very quickly), and its code isn't 
particularly reusable, because it's only usable within the 
framework. So, from the perspective of a beginner or someone 
trying to get something done that doesn't require much 
flexibility, a framework might be a great solution. But as soon 
as you need to do anything that the framework folks didn't think 
of or which doesn't fit in well with how the framework is 
designed, you're pretty much screwed and forced to ditch the 
framework entirely. Contrast that with a library built entirely 
of reusable components that can be used to build functionality 
similar to that of the framework. It's probably going to be 
harder to use for some cases, because it's generally not doing as 
much for you out-of-the-box, but you can build what the framework 
does using the components it gives you, and you can build 
completely different stuff using those same components. You get a 
lot more flexibility and power out of it - but less hand-holding.

Good GUIs solve the common case well but don't generally do well 
for uncommon cases, and unlike command-line tools, they can't be 
used to build something else that isn't as common.

> But such suggestions are usually shot down by various standard 
> fallacies ("non-GUI == not user-friendly", "nobody uses CLI 
> anymore", "GUI == k00l, CLI == not k00l", etc.) and never 
> seriously considered, even though they really should be.

To be fair, for most people, CLI _isn't_ user-friendly - e.g. I 
sure wouldn't want to require that my mother use the command 
line. She has enough trouble with GUIs. As you mentioned, the 
problem is when everything is targeting the average joe and power 
users aren't given good tools. Having stuff that caters to the 
average joe is fine. It's when that's all they're doing that we 
have a problem.

- Jonathan M Davis