The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] The Unix shell: a 50-year view -- feedback wanted
@ 2021-07-09  4:49 Jon Steinhart
  2021-07-09  7:10 ` Noel Hunt
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: Jon Steinhart @ 2021-07-09  4:49 UTC (permalink / raw)
  To: tuhs

I not only found this paper offensive, but was more offended that
ACM would publish something like this and give it an award to boot.
I'm planning to send the authors and ACM what's below.  Would
appreciate any feedback that you could provide to make it better.

Thanks,
	Jon




I read your "Unix Shell Programming: The Next 50 Years" expecting
some well thought out wisdom from learned experiences.  I was
sorely disappointed.

 o  The paper never defines what is meant by the term "Unix shell."
    I think that you're using to mean a command interpreter as
    described in the POSIX 1003.2 documents.

 o  There is no 50 year old Unix shell.  I started using Unix in the
    early 1970s, and the command interpreter at the time (Ken Thompson's
    shell) was nothing like later shells such as the Bourne shell (sh
    since research V7 Unix), Korn shell (ksh), C shell (csh), and the
    Bourne again shell (bash).  The paper is missing any discussion of
    prior art.  In practice, shell implementations either predate the
    POSIX standard or were built afterwards and include non-standard
    extensions.

 o  The paper repeats a claim that the shell has been largely ignored by
    academia and industry.  Yet, it does not include any references that
    support that claim.  My own experience and thus opinion is the
    opposite making the veracity of your claim questionable.  As a reader,
    such unsubstantiated claims make me treat the entire content as suspect.

 o  The paper applies universal complaints such as "unmaintainable" to the
    shell; it doesn't call out any shell-specific problems.  It doesn't
    explain whether these complaints are against the scripts, the
    implementation, or both.  One of the reasons for the longevity of the
    sh/bash shells is that experienced practicioners have been able to
    write easily maintainable code.  Scripts written in the 1980s are
    still around and working fine.

 o  The paper seems to complain that the fact that the shell is documented
    is a problem.  This is an astonishing statement.  In my decades as an
    acting professional, teacher, and author, proper documentation is a key
    component of being a professional.

 o  The paper is full of non-sequiturs such as discussions about Docker
    and systemd that have nothing to to with the shell.

 o  The paper has many "nop" statements such as "arguably improved" that
    don't actually say anything.

 o  Examples, such as the one on page 105 don't work.

 o  Proofreading should have caught things like "improve performance
    performance" on page 107 among others.

 o  The references contain many more items than the paper actually
    references.  Did you plagerize the bibliography and forget to
    edit it?

 o  The single result in Figure 1 is insufficient evidence that the
    approach works on a wide variety of problems.

 o  The paper makes it appear that the authors don't actually understand
    the semantics of the original Bourne shell.  Not just my opinion; I
    received an email from Steve Bourne after he read your paper, and I
    consider him to be a subject matter expert.

The paper is lacking the generally accepted form of:

 o  What problem are you trying to solve?
 o  What have others done?
 o  What's our approach?
 o  How does it do?

Filtering out all of the jargon added for buzzword compliance, I think
that the paper is really trying to say:

 o  Programmable command interpreters such as those found in Unix-based
    systems have been around for a long time.  For this paper, we're
    focusing on the GNU bash implementation of the POSIX P1003.2 shell.
    Other command interpreters predate Unix.

 o  This implementation is used more often than many other scripting
    languages because it is available and often installed as the default
    command interpreter on most modern systems (Unix-based or otherwise).
    In particular, it is often the default for Linux systems.

 o  The shell as defined above is being used in ways that are far more
    complex than originally contemplated when Bourne created the original
    syntax and semantics, much less the new features added by the POSIX
    standards committee.  The combination of both the POSIX and bash
    extensions to the Bourne shell exposes a new set of limitations and
    issues such as performance.

 o  While much work has been done by the bash implementors, it's primarily
    been in the area of expanding the functionality, usually in a
    backward-compatible manner.   Other shells such as the original ksh and
    later ash and zsh were implemented with an eye towards the performance
    of the internals and user perspectives.

 o  Performance optimization using modern techniques such as JIT have been
    applied to other languages but not to POSIX shell implementations.  This
    paper looks at doing that.  It is unsurprising that techniques that have
    worked elsewhere work here too.

 o  It's hard to imagine that the application of this technique is all that's
    required for a 50-year life extension.  The title of this paper implies
    that it's going to be comprehensive rather than just being a shameless
    plus for an author's project.

Of course, this doesn't make much of a paper.  Guessing that that's why it
was so "bulked up" with irrelevancies.

It appears that all of you are in academia.  I can't imagine that a paper
like this would pass muster in front of any thesis committee, much less
get that far.  Not only for content, but for lack of proofreading and
editing.  The fact that the ACM would publish such a paper eliminates any
regret that I may have had in dropping my ACM membership.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [TUHS] The Unix shell: a 50-year view -- feedback wanted
  2021-07-09  4:49 [TUHS] The Unix shell: a 50-year view -- feedback wanted Jon Steinhart
@ 2021-07-09  7:10 ` Noel Hunt
  2021-07-09 13:26 ` Larry McVoy
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: Noel Hunt @ 2021-07-09  7:10 UTC (permalink / raw)
  To: Jon Steinhart; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 436 bytes --]

Allow me to express my thanks to you for doing this.

Noel Hunt

On Fri, Jul 9, 2021 at 2:51 PM Jon Steinhart <jon@fourwinds.com> wrote:

> I not only found this paper offensive, but was more offended that
> ACM would publish something like this and give it an award to boot.
> I'm planning to send the authors and ACM what's below.  Would
> appreciate any feedback that you could provide to make it better.
>
> Thanks,
>         Jon
>

[-- Attachment #2: Type: text/html, Size: 1061 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [TUHS] The Unix shell: a 50-year view -- feedback wanted
  2021-07-09  4:49 [TUHS] The Unix shell: a 50-year view -- feedback wanted Jon Steinhart
  2021-07-09  7:10 ` Noel Hunt
@ 2021-07-09 13:26 ` Larry McVoy
  2021-07-09 19:23 ` John Cowan
  2021-07-09 20:26 ` Theodore Ts'o
  3 siblings, 0 replies; 5+ messages in thread
From: Larry McVoy @ 2021-07-09 13:26 UTC (permalink / raw)
  To: Jon Steinhart; +Cc: tuhs

I think it is great as it stands (yeah, I read all of it).  If there
is a way I can sign it as well, not as an author, just as an "I agree
with everything here", tell me and I'll sign.

I continue to be dismayed at the state of the art these days, seems like
there is no art, but to have the ACM award this crap is depressing.

On Thu, Jul 08, 2021 at 09:49:37PM -0700, Jon Steinhart wrote:
> I not only found this paper offensive, but was more offended that
> ACM would publish something like this and give it an award to boot.
> I'm planning to send the authors and ACM what's below.  Would
> appreciate any feedback that you could provide to make it better.
> 
> Thanks,
> 	Jon
> 
> 
> 
> 
> I read your "Unix Shell Programming: The Next 50 Years" expecting
> some well thought out wisdom from learned experiences.  I was
> sorely disappointed.
> 
>  o  The paper never defines what is meant by the term "Unix shell."
>     I think that you're using to mean a command interpreter as
>     described in the POSIX 1003.2 documents.
> 
>  o  There is no 50 year old Unix shell.  I started using Unix in the
>     early 1970s, and the command interpreter at the time (Ken Thompson's
>     shell) was nothing like later shells such as the Bourne shell (sh
>     since research V7 Unix), Korn shell (ksh), C shell (csh), and the
>     Bourne again shell (bash).  The paper is missing any discussion of
>     prior art.  In practice, shell implementations either predate the
>     POSIX standard or were built afterwards and include non-standard
>     extensions.
> 
>  o  The paper repeats a claim that the shell has been largely ignored by
>     academia and industry.  Yet, it does not include any references that
>     support that claim.  My own experience and thus opinion is the
>     opposite making the veracity of your claim questionable.  As a reader,
>     such unsubstantiated claims make me treat the entire content as suspect.
> 
>  o  The paper applies universal complaints such as "unmaintainable" to the
>     shell; it doesn't call out any shell-specific problems.  It doesn't
>     explain whether these complaints are against the scripts, the
>     implementation, or both.  One of the reasons for the longevity of the
>     sh/bash shells is that experienced practicioners have been able to
>     write easily maintainable code.  Scripts written in the 1980s are
>     still around and working fine.
> 
>  o  The paper seems to complain that the fact that the shell is documented
>     is a problem.  This is an astonishing statement.  In my decades as an
>     acting professional, teacher, and author, proper documentation is a key
>     component of being a professional.
> 
>  o  The paper is full of non-sequiturs such as discussions about Docker
>     and systemd that have nothing to to with the shell.
> 
>  o  The paper has many "nop" statements such as "arguably improved" that
>     don't actually say anything.
> 
>  o  Examples, such as the one on page 105 don't work.
> 
>  o  Proofreading should have caught things like "improve performance
>     performance" on page 107 among others.
> 
>  o  The references contain many more items than the paper actually
>     references.  Did you plagerize the bibliography and forget to
>     edit it?
> 
>  o  The single result in Figure 1 is insufficient evidence that the
>     approach works on a wide variety of problems.
> 
>  o  The paper makes it appear that the authors don't actually understand
>     the semantics of the original Bourne shell.  Not just my opinion; I
>     received an email from Steve Bourne after he read your paper, and I
>     consider him to be a subject matter expert.
> 
> The paper is lacking the generally accepted form of:
> 
>  o  What problem are you trying to solve?
>  o  What have others done?
>  o  What's our approach?
>  o  How does it do?
> 
> Filtering out all of the jargon added for buzzword compliance, I think
> that the paper is really trying to say:
> 
>  o  Programmable command interpreters such as those found in Unix-based
>     systems have been around for a long time.  For this paper, we're
>     focusing on the GNU bash implementation of the POSIX P1003.2 shell.
>     Other command interpreters predate Unix.
> 
>  o  This implementation is used more often than many other scripting
>     languages because it is available and often installed as the default
>     command interpreter on most modern systems (Unix-based or otherwise).
>     In particular, it is often the default for Linux systems.
> 
>  o  The shell as defined above is being used in ways that are far more
>     complex than originally contemplated when Bourne created the original
>     syntax and semantics, much less the new features added by the POSIX
>     standards committee.  The combination of both the POSIX and bash
>     extensions to the Bourne shell exposes a new set of limitations and
>     issues such as performance.
> 
>  o  While much work has been done by the bash implementors, it's primarily
>     been in the area of expanding the functionality, usually in a
>     backward-compatible manner.   Other shells such as the original ksh and
>     later ash and zsh were implemented with an eye towards the performance
>     of the internals and user perspectives.
> 
>  o  Performance optimization using modern techniques such as JIT have been
>     applied to other languages but not to POSIX shell implementations.  This
>     paper looks at doing that.  It is unsurprising that techniques that have
>     worked elsewhere work here too.
> 
>  o  It's hard to imagine that the application of this technique is all that's
>     required for a 50-year life extension.  The title of this paper implies
>     that it's going to be comprehensive rather than just being a shameless
>     plus for an author's project.
> 
> Of course, this doesn't make much of a paper.  Guessing that that's why it
> was so "bulked up" with irrelevancies.
> 
> It appears that all of you are in academia.  I can't imagine that a paper
> like this would pass muster in front of any thesis committee, much less
> get that far.  Not only for content, but for lack of proofreading and
> editing.  The fact that the ACM would publish such a paper eliminates any
> regret that I may have had in dropping my ACM membership.

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [TUHS] The Unix shell: a 50-year view -- feedback wanted
  2021-07-09  4:49 [TUHS] The Unix shell: a 50-year view -- feedback wanted Jon Steinhart
  2021-07-09  7:10 ` Noel Hunt
  2021-07-09 13:26 ` Larry McVoy
@ 2021-07-09 19:23 ` John Cowan
  2021-07-09 20:26 ` Theodore Ts'o
  3 siblings, 0 replies; 5+ messages in thread
From: John Cowan @ 2021-07-09 19:23 UTC (permalink / raw)
  To: Jon Steinhart; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]

On Fri, Jul 9, 2021 at 12:50 AM Jon Steinhart <jon@fourwinds.com> wrote:

I not only found this paper offensive, but was more offended that
> ACM would publish something like this and give it an award to boot.
> I'm planning to send the authors and ACM what's below.  Would
> appreciate any feedback that you could provide to make it better.
>

I too would like to (virtually) sign this.

I also point out (not for inclusion in your piece) that the fastest path to
fame and what in academia counts as fortune is to write a paper with a
superficially plausible argument that some well-known fact or
well-established conclusion is wrong.  This immediately draws the mantle of
Galileo over the author, but instead of the author being imprisoned for
life by the Papal Inquisition, the paper becomes the subject of raves, the
author becomes a hero, and the discipline may even be said to have taken a
new turn as everyone rushes to follow and compete.

But often the little boy in "The Emperor's New Clothes" is either deluded
or trying to gain glory by daring to annoy the Emperor.

[-- Attachment #2: Type: text/html, Size: 2297 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [TUHS] The Unix shell: a 50-year view -- feedback wanted
  2021-07-09  4:49 [TUHS] The Unix shell: a 50-year view -- feedback wanted Jon Steinhart
                   ` (2 preceding siblings ...)
  2021-07-09 19:23 ` John Cowan
@ 2021-07-09 20:26 ` Theodore Ts'o
  3 siblings, 0 replies; 5+ messages in thread
From: Theodore Ts'o @ 2021-07-09 20:26 UTC (permalink / raw)
  To: Jon Steinhart; +Cc: tuhs

On Thu, Jul 08, 2021 at 09:49:37PM -0700, Jon Steinhart wrote:
>  o  It's hard to imagine that the application of this technique is all that's
>     required for a 50-year life extension.  The title of this paper implies
>     that it's going to be comprehensive rather than just being a shameless
>     plus for an author's project.

Spelling nit: I believe you meant to say "shameless plug..." (s/plus/plug/)

> It appears that all of you are in academia.  I can't imagine that a paper
> like this would pass muster in front of any thesis committee, much less
> get that far.  Not only for content, but for lack of proofreading and
> editing.  The fact that the ACM would publish such a paper eliminates any
> regret that I may have had in dropping my ACM membership.

It looks like this was originally a position paper for the Workshop on
Hot Topics in Operating Systems (aka HotOS).  As a workshop paper, it
would have had a much lower standard of than say, if this was being
presented at say, SOSP or ASPLOS.  Workshop papers are supposed to be
provocative and suggest "new directions".  Sometimes new directions
turn out to just be dead ends, and while some things presented at
workshops will grow up to be a full paper at a highly respected
conference, other ideas get presented at a workshop and are never
heard from again.  :-)

I'd have to think to come up with examples, but I'm pretty sure I've
seen sillier ideas as workshops papers.  More impractical ideas, for
certain.

I have observed that the things that will get funding for academic
research, and things which are considered interesting from a industry
or practitioner's perspective, tends to diverge in any field, and the
divergence increases over time.

It might or might not be the case that "the shell is a promising area
of research".  Even if it is true, there are plenty of things which
generate research papers, and serve to help education graduate
students, but which ultimately end up being completely useless from
the industry practitioners perspective.  I may be overly cynical, but
there are plenty of papers at many a conference, even highly respected
ones by tenture-track committees, which inspires nothing but a yawn
from me, and personally, that doesn't bother me; what consenting
adults do within the confines of academia is their business.

Again, I've seen worse in terms of "my tax dollars at play".

If we're lucky, even if the actual object of the research is useless,
sometimes it can sparc some insight that makes my time spent at such a
conference not a complete waste --- and even if it isn't at least
it's fertile recruiting ground for new college grads for $WORK. :-)

      	   	   	      	     	     - Ted

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-07-09 20:26 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-09  4:49 [TUHS] The Unix shell: a 50-year view -- feedback wanted Jon Steinhart
2021-07-09  7:10 ` Noel Hunt
2021-07-09 13:26 ` Larry McVoy
2021-07-09 19:23 ` John Cowan
2021-07-09 20:26 ` Theodore Ts'o

The Unix Heritage Society mailing list

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/tuhs

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 tuhs tuhs/ http://inbox.vuxu.org/tuhs \
		tuhs@minnie.tuhs.org
	public-inbox-index tuhs

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.tuhs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git