DUB - call to arms

Nick Sabalausky (Abscissa) SeeWebsiteToContactMe at semitwist.com
Sat Apr 27 20:41:56 UTC 2019


On 4/26/19 1:30 PM, H. S. Teoh wrote:
> See, this is the problem I have with many supposedly "modern" tools.
> They are giant CPU and memory hogs, require tons of disk space for who
> knows what, take forever to start up, and chug along taking their sweet
> time just to get the simplest of tasks done, where supposedly "older" or
> "antiquated" tools fire up in an instant, get right to work, and get the
> same task done in a fraction of the time.  This in itself may have been
> excusable, but then these "modern" tools also come with a whole bunch of
> red tape, arbitrary limitations, and the philosophy of "follow our way
> or walk there on foot yourself".  IOW they do what "antiquated" tools do
> poorly, and can't even do advanced things said "antiquated" tools can do
> without any fuss -- and this not because of *technical* limitations, but
> because it was arbitrarily decided at some point that use cases X and Y
> will not be supported, just 'cuz.

+1

> So somebody please enlighten this here dinosaur of *why* I should choose
> these "modern" tools over my existing, and IMO better, ones?

Because "you just have to believe" and join the newer-is-always-better 
cult? Because we're told by everyday joe that we always have to keep up 
with new technology or get left behind, so by golly that must be true, 
after all, who are we to question those smarter than us, those from whom 
everyday joe obtained the "keep up or left behind" Truth?

I think THAT'S why you have to. ;)

> 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.
> 
> (The jewel-encrusted box is still nice, BTW -- but only as long as it's
> not at the expense of welding the hood shut.)

Unix philosophy. Yup. *nods*. "A tool should do one thing, and do it 
well." The Lego approach to software.

I grew up on MS-DOS and Windows (well, ok, Apple 2...then DOS/Win). And 
hey, they served their purposes for me. Fast-forward some years later 
and I was talking to a game programmer I had previously known (gamedev 
circles tend to be fairly Win/MS-heavy - and there's admittedly been 
reasons for that). At one point he stopped and said, "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.

It's also why a world of random hackers have been able to build and 
maintain a system that, in terms of capabilities, even giants like 
Microsoft and Google can't keep up with (although, certain business 
realities actually make it much more lucrative for large companies to 
keep their products artificially limited - so it's not as if they're 
especially motivated to compete with *nix on capabilities).


More information about the Digitalmars-d mailing list