On Sat, Aug 31, 2019 at 11:38:59AM -0400, The Wanderer wrote:
>
> I don't think I'd prefer it, because it would mean I'd have to remember
> where I left the cursor last time rather than being able to just assume
> it will always be in a particular position, but I can see that being
> just a result of what I'm used to; I could see this being a better
> behavior in the large, if one got used to it first.
>
> (It seems as if would be kind of hard to implement, since you'd have to
> embed a cursor position per-line into the command history file, but
> that's another discussion.)
>
> I don't suppose you know of any shells which have that behavior, even as
> an option?
>
I am not aware of such a shell, though I have a vague recollection of an
IDE that included an interactive shell component that did something
similar. However, that was ages ago and I don't even recall what
language the IDE was for.
>
> But much less, and certainly not with every pipeline command - whereas
> your suggested form, with punctuation at the end, means having to do it
> every time.
>
I'll agree to disagree here.
>
> Just because I only type the command once doesn't mean that I want to
> type a more complex command than I need to.
>
Whereas I'd rather front-load the complexity for the repeated benefit of
additional simplicity for every future occurrence.
>
> I'm not sure exactly what optimizations, or benefit, you're referring
> to. Aside from argument towards elegance, and possibly performance
> optimization of some form, I'm not sure I see any benefit of the forms
> you're suggesting.
>
To me, the benefit is in being able to quickly and unambiguously
separate "interesting" logic from "non-interesting" parts of the
command. We obviously have different views on how this could be
beneficial or even what constitutes "interesting" vs. "non-interesting"
parts.
>
> But I don't have to spend any time on separating the two. The beginning
> of the command is where the input comes in; the end is where it goes
> out; everything else is functional.
>
> The form you provided that puts both at the end is complex and confusing
> enough that I can't parse it at a glance; doing so only takes me a
> second or two, but I do have to stop and do it, in what I suspect is
> much the same way you have to stop and separate out the functional from
> the input-handling in my preferred idiom.
>
> Again, there's nothing wrong with your approach. What I'm saying is that
> there's also nothing wrong with mine, and yet I get called out for using
> (or even suggesting) it, for what as far as I can tell are purely
> historical reasons.
>
In my case I have trained myself to quickly parse the form I described.
Those extra characters and constructs, which some might argue are visual
clutter, are to me clean separators between the parts I can safely
ignore and the parts where I should focus my effort.
In any event, I agree that there is nothing inherently wrong with your
approach, though I would find it more difficult to effectively reason
about the start of the "interesting" part of a command in your preferred
construct.
>
> I disagree that the way the alternatives described accomplish that task
> is better.
>
> (Most of them, anyway. Teemu's suggestion seems obviously superior, at
> least at a glance, and I may well adopt it going forward.)
>
Yeah, I have to say that I'm not really sure I knew that could be done.
> I could try to break apart and analyze my reasons at length, but I kind
> of doubt that the result would be all that productive.
>
It might not be for us, but you may find it useful to do that for
yourself.
> >
> > The same effect could have been achieved by making the first line a
> > '(' and the last as ')' for the subshell enclosure.
>
> That's an interesting thought. I'll try to keep it in mind for the next
> time I'm doing something like that.
>
Another benefit of the subshell is that variables set within the
subshell automatically go out of scope when the subshell terminates.
For instances where I have to set lots of environment variables and I
don't want to have to clean them up manually after, the subshell is a
nice way to make sure my existing environment stays clean.
>
> I can see the argument for clutter, but for my purposes, the extra
> syntax of the forms you've suggested are even more clutter and make the
> result even harder to read, thereby making it even harder to quickly
> discern what is really happening.
>
> I suspect that this just boils down to minds working differently.
>
True. Over time my thoughts on what constitutes clutter, easy to read
code in various languages, etc. has changed. Looking back over old code
that I've written years ago is a real treat.
I have actually found myself saying things like, 'what moron wrote this
garbage?!?!' Then looking at the git history to find that the moron was
me a few years ago :-)
Regards,
-Roberto
--
Roberto C. Sánchez
