Hacker News Reader

Comment by tclancy | Hacker News Reader

I am with the author on the general point. But I think it ignores the fact discussing how things were in the '60s when the commands were written just for people ignores a fundamental change. To wit:

>the added options are convenience flags: setting the permissions of the new directory and making parent directories if they don't exist.

Obviously completely unnecessary for normal users, but those have to exist for automated processes. The "problem" is caused in part by the success of Unix, that now computers are using computers.

View on HN

But he doesn't ignore it... the last paragraph says:

> To be clear, I'm not saying that I or anyone else could have done better with the knowledge available in the 70s in terms of making a system that was practically useful at the time that would be elegant today. It's easy to look back and find issues with the benefit of hindsight. What I disagree with are comments from Unix mavens speaking today, with comments like McIlroy's, which imply that we just forgot or don't understand the value of simplicity, or Ken Thompson saying that C is as safe a language as any and if we don't want bugs we should just write bug-free code. These kinds of comments imply that there's not much to learn from hindsight, we were building things as well as anyone could build things in the 70s, all we have to do is go back to building systems like the original Unix mavens and all will be well. I respectfully disagree.

In other words, the real problem isn't that modern software is getting more complex (as there is a good reason for it); the problem is that we're insisting on using an environment that is not up to the task of dealing with modern complexity.

For an example of how insane this world is: consider putting your source trees in a location that contains a space in its name. How many build systems are going to completely and utterly fail to build your code? And... why should we tolerate this situation?

If you believe mkdir -p is completely unnecessary for normal users and only exists for scripting, you probably want to think about how it might fit into your workflow again. In fact, my mkdir is simply aliased to mkdir -p, and I have a self evidently-named wrapper function called mkcd which I use even more often than mkdir.

I immediately second-guessed my use of "Obviously completely"-- what I meant was "We can get by without it" whereas a standalone script cannot.

Well a script can do path parsing too, it’s just rather painful. Similar (actually more complex) real world task that does get implemented in POSIX sh: realpath(1) replacement, when it doesn’t exist.

Since one can alias commands to functions, that does suggest that in fact mkdir -p is actually unnecessary.

High level languages aren’t necessary because you can program in assembly too.

But then you would have to bring your own aliases everywhere. And common aliases just got upstreamed.

Wait, what does mkcd do?

    function mkcd() {
        mkdir -p -- "$1" && cd -P -- "$1"
    }

I'm guessing makes a directory, with paths, then cds into it.

I assume `mkdir $@ && cd $@`

I think that’s backwards: it’s a convenience function for interactive use.

Sure it’s convenient for writing scripts too but a script could just as well include some boilerplate for the functionality if required and it if not.

This is the argument between CISC and RISC.

Reply on news.ycombinator.com