I agree. For instance, with cars, the essence of a car is driving, and hence the only thing that a common user cares about is learning how to drive one. In particular, a common user should not need, and are usually not interested in, having automechanic skills. On the contrary, that's the whole point of car manufactures and workshops, so that a common user doesn't have to care about those technical details under the hood, but just focus on the main task i.e. driving.

I think it's similar with computers and programs. The essence of a computer is information, so the main skill a common person needs is knowing how to work with information e.g. in the present day, navigate the web safely, how to research appropriately + identify reliable sources, organize and analyze data, manage privacy, etc They shouldn't have to be programmers themselves, and indeed, that's the whole point of software, so that a common person can focus on their main task of working with information, and not have to be concerned about technical details under the hood.

note: things like excel macros where a software has a programming-like feature is a different matter, since it's a feature exposed explicitly by the software for users to exploit if need be. In any case, it's a software choice and hence specific only to that software.

I also agree. In fact, I have a feeling it is not simply a matter of allure, but one of the most decisive and important factors if not the single most.

I think we tend to underestimate the importance of this kind of uniformity (aka homogeneity, consistency, sameness, equivalence etc) that allows us to freely shift back and forth and work across different environments (aka contexts, mindsets, etc) without any essential changes and translations. i.e. in a sense, minimizing the boundary such that the difference effectively disappears and it feels as if it's all just one same. In this case the environments being shell <-> script. But I think I see similar patterns in many other places, including outside of tech.

So, similar to as you also mentioned, as long as there is no language that beats the current shell as both a shell language and a scripting language, and one that sufficiently matures for real practical uses as both, I have a hard time imagining the most perfect scripting language alone still being able to make shell scripts go away. At least, I have a hard time imagining myself abandoning shell scripts otherwise.

More a question than a comment: if you think it's all only decline now and were really done with life, why are you still here? If you were truly done all the way through, I'm sure you would have long done away with life without even questioning it. But you haven't and are still here. Great! I think this fact means something: there is still something holding you here, no matter how seemingly small and trivial. And somehow I get the feeling the secret is actually somewhere in there, whatever it may be. And so maybe it's not really that small and trivial.

p.s. I've been running in circles like this myself for decades..

I am rather skeptical it is a matter of software or any tool for that matter with problems like this.

Similar to Paul Grahma's design paradox: " I call it the design paradox. You might think that you could make your products beautiful just by hiring a great designer to design them. But if you yourself don't have good taste, how are you going to recognize a good designer?" (http://www.paulgraham.com/gh.html)

As long as people (including the business owners, customers, the rest of society, the rest of the world, etc) don't recognize the cost or don't care sufficiently even if they do recognize it, the best tool still won't have any effect nevermind solve. Usually, that's the critical problem, not the tools. And of course, tools won't fix people either. Software is useful only if used by the right people in the right way, which is usually much later.

In general, I'm pretty skeptical of imperative guides like this. Such statements only focus on one side of the coin. So while it may have an element of truth as long as you are absorbed only on that one side, you risk completely missing the other side.

For example: > Deprecate yourself. ... Don't own the code.

On one hand, this is true: ultimately, you want the code to be independent of you. But on the other hand, I've witnessed bad code quality proliferate in a repo many times because no one is taking ownership of the code they write: they just write enough to finish the task and move on. And it rarely gets caught in code reviews either because all the other members are operating in the same mindset too. His principle misses this side of the coin.

Over the years, I came to realize that at least for me, there is one root force behind almost everything for me, including how I code, how I interact with members, etc. It is: responsibility. I am simply trying my best to write responsible code, create a responsible product, be responsible to my team members and colleagues, etc. The rest of the stuff (like what you might call 'principles') are just specific manifestations of this feeling. e.g. code ownership: I need to own my code to the extent that I need to be responsible for my work, but on the other hand, it is also my responsibility to ensure the code does not depend on me forever. Albeit this probably may be too abstract to call a principle. In that case, I'd rather not have any.

It depends on the type of relationship to some extent e.g. friends, acquaintances, business relations, etc.

But in general, I feel like we are too self-conscious about staying in touch. And often because we have experiences where something happens in our lives and we find ourselves regretting "I wish I had stayed in touch with ----".

But when that happens, maybe we can ask ourselves: even if I had stayed in touch, would it really have turned out as I am fantasizing now in my regret? If we think about it carefully, I think the answer is probably no. A meaningful relationship is not that simple nor easy.

As others have mentioned, a relationship is two-ways so it takes both sides. And it only takes one to remember occasionally to stay in touch, so if we both were interested in each other, most likely we would have remained in touch already. And even if we had not, it's never too late. With such relations, I find that I can just reach out now and resume the same relationship no matter how much time passes in between. Even in the worst case where I don't have the contact anymore, if I were truly determined, I will do everything I can to find a way to reach that person.

On the other hand, a shallow relation is bound to not get too far: it will fail (or break, or be lost, etc) at some point in one way or another anyway. So it most likely wouldn't have turned out as my regret is fantasizing anyway.

> A lot of senior experienced people will talk about all the “shoulds” your code should be like.

And the article itself is another "should".

I agree, there is often a deep discrepancy. The things people say (like what they say they believe, what they say they value, etc) often do not match up with what they actually think (e.g. if you watch how they actually behave, make choices, go about their lives, etc).

I sometimes hear people say it's a matter of how you define words like "believe" but to me, that only to complicates the matter.

I think almost all if not all of our serious problems can be traced to this kind of discrepancy. Maybe that's my outrageous belief, heh :S

I almost completely agree with what you say, except to me it seems there are other forms of denial as well, and I don’t know how common they are compared to each other.

Yes, it is possible to play with the words like redefine ”belief”, but does not get us any closer to the truth.