Looking to the future (was Re: Light weight support for JSON)

[Martin D Kealey]

Not that I fundamentally disagree with this (JSON) proposal, but I'd rather
see the effort put into support for nested arrays (like ksh has), and
generally having a more forward-looking view of Bash as an evolving
language.

I would see this proceeding somewhat like the transition from Perl4 to
Perl5, where "everything is a string" gets replaced by a functioning
polymorphic type system that by default provides what look like the same
strings as before, but under the hood uses direct references rather than
symbolic indirection. (Yes, that would finally fix "local -n".)

Then emitting JSON or YAML becomes simply a matter of defining an output
formatter for a structured variable, which could even be set as its default
"stringize" function with a suitable "declare" statement.

It used to be that POSIX sh and AWK were the only common languages that
could be assumed to be present on all systems. Somewhere along the way AWK
fell out of common awareness, leaving just the shell, with its
arcane-to-the-point-of-intentionally-harmful misfeatures.

Since 1990, we've moved on. Systems have - quite literally - a million
times more storage than when POSIX documented the state of play in 1987.

In POSIX-like systems, tools like Python, Ruby, Perl & PHP have become
ubiquitous. Moreover, packaging systems allow a script to declare its
prerequisites, including its interpreter, so it's no longer necessary to
target one "universal" language.

Even embedded systems have many gigabytes of storage and generally include
a range of tools such as Perl and/or Python, or at least can install them.
(Those that don't generally also lack the ability to install *anything*,
including shell scripts, which makes the question of "which scripting
language" entirely moot.)

Supporting new features on *really* older devices is hard to justify, as
such devices are being replaced *just to reduce their power consumption*.

The Shell persists because it has one killer feature: it does double duty
as a scripting language and as an interactive command language. But we're
kidding ourselves if we think that no other language could fill that gap:
Python has a respectable interactive mode, though its focus is on objects
rather than processes and files; the interactive "debugger" console inside
Firefox speaks Javascript; and even "perl -d" is almost usable.

As for the future, I believe that if we don't move towards making the POSIX
sh behaviour a truly optional part of an otherwise-more-sane language, we
condemn Bash to continued obscurity and eventual extinction.

Existing shell scripts aren't going to curl up and die any time soon, but
we're at a crossroads: either we admit that Bash has had its day, and stop
adding ANY new features, or we make a decision to let it evolve in ways
that will still run existing scripts, provide an effective command
language, *and* allow new scripts to be written without needing to
constantly work around misfeatures that are 35 years past their use-by date.

Which is it to be?

-Martin

PS: top of my list of most-hated misfeatures isn't any of the POSIX
malapropisms, but rather the fact that we can't write "shopt compatXX" with
the XX being the newest Bash version, and be sure that when person A
eventually installs a future version of Bash to get its new whiz-bang
interactive features, it won't break a script written by person B.

I've been told that "shopt compat" is a "short term measure until the
script gets fixed".
Implicit in that is the assumption that either the author of a Bash script
is supposed provide eternal on-going preemptive updates (even to users who
didn't even get the original from them), or that people who install a
script must necessarily be capable of diagnosing the weird broken behaviour
that emerges when they install a new version of Bash.
Yes, both of those are as crazy as they sound, and so is the "short term
measure".