Chet Ramey wrote:
I understand the problems of working with 10+ year old code that's
been patched through the roof and trying to add _anything_ to the
design. Thus the proposal of keeping the idea around if bash was
ever refactored such that implementing a change like this wouldn't be
a big deal....
You misunderstand. The implementation difficulty, such as it is, is
secondary to whether or not changing the grammar like that is a good
idea in the first place. I don't think it is, and I don't think that
adding syntactic sugar is a compelling reason to change that.
====
That URL I mentioned included *shell*, by a hair, as being the *most
wordy* to get anything done in the top-tier popularity group. The
median differences between the low and high expressive groups was 31X
(i.e. the low-expressive langs took 31 times as many lines to do the
same thing as high-expressive langs. The main thing that helped shell
was *consistency* though it was also one of the more wordy, less
readable and less maintainable.
(URL
=
http://redmonk.com/dberkholz/2013/03/25/programming-languages-ranked-by-expressiveness/
)
Shellscript made the bottom of the cutoff for the tier-one popularity.
No tier-one languages fall in the top 25 on both metrics, although
5 make the cut on consistency alone. Of the tier-one languages,
lower-level ones tend to be both inconsistent and overly wordy, while
higher-level ones have intermediate wordiness and very strong
consistency.
The most consistent languages are Python, Objective-C, Perl, C#, and
***shell***, ***with the presence of *Perl* and *shell* supporting
the initial assertion that:
**expressiveness has little to do with readability or maintainability**.
I.e. shell is at the bottom in terms of readability and
maintainability. <<<<
According to this study and the rosetta-stone study (comparing same-prob
implementations in different languages), *SHELL* is in drastic need of
improvements in readability and maintainability --- which is exactly
what we are talking about in creating syntax simplifications that make
it more readable and increase maintainability.
Your dismissive attitude of readability and maintainability as
"syntactic sugar" is unfortunate -- *IF* the implementation of such
became easier due to refactoring.
The difficulties in creating such simple extensions speaks to
maintainability.
I well understand that point -- in so much that I wrote a 'snapshot'
program in shell -- @938 lines. It worked, but the first time something
needed to change, it was unmaintainable and inextensible, despite my
best efforts to make it so. It was a state machine -- that kept track
of what it had done -- so that it wouldn't lose data or overwrite data.
sections of code called checks for dependencies and added flags for
positive checks.
Eventually rewrote it in perl (only slightly more maintainable) -- but
with considerably more error checking and checkpointing so if a problem
arose, usually, simply re-running the script found the last good step,
and recovered from there. Due to all the extra transaction recording
and checking, the perl version's main program ran 2343 lines (which
isn't including multiple libraries that got written.
What you and Andreas seem to dismissively call syntactic sugar is
increased ease of use, maintainability and a lower overall bug-count due
to the need of fewer lines. "Syntactic sugar" isn't gratuitous sugar.
