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
