DUB - call to arms

[H. S. Teoh]

On Sat, Apr 27, 2019 at 04:41:56PM -0400, Nick Sabalausky (Abscissa) via Digitalmars-d wrote:
> On 4/26/19 1:30 PM, H. S. Teoh wrote:
[...]
> > This is why I'm a fan of empowering the user.  Instead of being
> > obsessed over how to package your software in a beautiful
> > jewel-encrusted box with a gold ribbon on top, (which IMO is an
> > utter waste of time and only attracts those with an inflated sense
> > of entitlement), give the user the tools to do what the software can
> > do. Instead of delivering a magic black box that does everything but
> > with the hood welded shut, give them the components within the black
> > box with which they can build something far beyond what you may have
> > initially conceived.  I believe *that* is the way to progress, not
> > this "hand me my software on a silver platter" philosophy so
> > pervasive nowadays.
[...]
> Unix philosophy. Yup. *nods*. "A tool should do one thing, and do it
> well." The Lego approach to software.

It's not so much doing one thing and doing it well (even though that is
a natural consequence), but (1) giving the user access to the tools that
*you* have at your disposal, and (2) making the interface *composable*,
so that the user is empowered to put the blocks together in brand new
ways that you've never thought of.


[...]
> "Hey, wait a minute, since when did you become a Linux guy?" Well,
> since I grew up and learned that I like being able to automate any
> repetitive sequence I need to, to aid my productivity and help manage
> cognitive load. The unix philosophy is key in enabling that.
[...]

Yes, the ability to automate *any arbitrary task* is a key functionality
that modern designs seem to have overlooked. Automation is the raison
d'etre of the first machines.  Humans are bad at repetitive tasks, and
machines are supposed to take over these tasks so that humans can excel
at the other things they are good at.

Yet the UIs of the modern day force you to click through endless nested
levels of submenus and provide very little (if any at all) way to
automate things.  And when such is provided, it's usually arbitrarily
limited or encumbered in some way, and usually cannot come up to the
full functionality accessible when you do things the manual way.  It
doesn't make any sense.  Machines are supposed to abstract away the
repetitive tasks and allow you to program them to do arbitrary things on
the click of a button, not to force you to make repetitive gestures and
get a wrist aneurysm because the GUI designer didn't think scripting was
an important use case.  The whole point of a general-purpose computing
machine is to be able to apply this automation to ANY ARBITRARY TASK,
not merely some arbitrarily limited subset that the designers deigned
worthy to be included.

Making your interface composable is what allows your code to be
composable with any other code in a painless way.

This is why more and more in my own designs I'm leaning towards the
guiding principle of programs being thin wrappers around reusable
library modules that provide the real functionality. And the programs
themselves should as much as possible provide the simplest, most
straightforward interface that makes it composable with any other
arbitrary program.

Composability, because the user is smarter than you and will think of
use cases far beyond your wildest imaginations, so they should not be
arbitrarily limited to only what you can think of.

Libraries, because no matter how awesome your program interface is,
eventually somebody will want to reuse your functionality from their
*own* program.  Allowing them to do that without needlessly cumbersome
workarounds like spawning a subprocess and contorting their code to your
quirky CLI syntax or method of invocation will make them very happy and
loyal users, and will increase the scope of applicability of your code
far beyond what you may have conceived.

(And no, remote procedure call is not an excuse to avoid providing a
library API to your functionality.  RPC has its uses, but the user
should be in control of how they wish your code to run. They should not
need to spawn a daemon via JSON over HTTP to a remote server just to be
able to call a single function. They *can* do this *if they want to*,
but this should not be the *only* way of interfacing with your code. The
user should be empowered to deploy your code according to *their* needs,
not yours. They should be able to choose whether to call your function
as a local function call to a DLL / .so on the local filesystem, or to
run your library on a remote server accessed via RPC over the network.)

Empower the user to do what *they* want, how they want it, rather than
straitjacket them to do what *you* want, the way you dictate it. This
principle applies to all levels of code, from not writing a class that
requires its methods to be called in a specific order otherwise it
crashes or gets into an inconsistent state, to encapsulating your
primary functionality in a library API that can be used anywhere in any
way.

Life is too short to be wasted inventing shims and workarounds to
functionalities that *should* have been made available generally with no
strings attached and no straitjackets imposing arbitrary limitations.
Empowerment, composability, automatability.  I'm tired of trying to work
with software that doesn't provide all three.  It's just not worth my
bother anymore.


T

-- 
MSDOS = MicroSoft's Denial Of Service