The only reason it's using a low number of lines of code is because the script is leveraging other Linux tools to handle everything other than reading input and concatenating a file with it. The...
The only reason it's using a low number of lines of code is because the script is leveraging other Linux tools to handle everything other than reading input and concatenating a file with it.
The tone of the article is also a bit inconsistent. The author starts by listing quotes about how software cannot be reasonably judged by the number of lines of code. But they do the same, except in the opposite direction.
And about his final statement: "with such a ridiculously small fraction of the code that one wonders why such complex systems even exist."
A big reason for this would be that those other apps are trying to be compatible with X number of platforms - devices, operating systems, browsers. This means that you can't simply "outsource" core functions of your software to implementations of the underlying OS, simply because they might not be there.
As an example, his script calls /usr/bin; AFAIK on MacOS, another UNIX OS, this directory isn't there, so the user needs to do some extra setup (symlink or edit the script) in order to work with it.
Anyway, it's a neat article for tech geeks, but the lessons learned can't really apply to any app that wants to appeal to some larger audience.
I thought the article was quite clear about intentionally not doing that and more so focusing on the leveraging of the neat abstractions that *nix provides and how these can easily compose into a...
But they do the same, except in the opposite direction.
I thought the article was quite clear about intentionally not doing that and more so focusing on the leveraging of the neat abstractions that *nix provides and how these can easily compose into a powerful system.
Perhaps I'm being pedantic for no good reason. Kudos to the guy for finishing & explaining a project. I just find it a bit ironic for someone to oppose counting many lines of code, and also...
Perhaps I'm being pedantic for no good reason. Kudos to the guy for finishing & explaining a project. I just find it a bit ironic for someone to oppose counting many lines of code, and also arguing for less. It would have been better if the article didn't mention this at all.
Despite the title seeming somewhat clickbaity (despite me toning it down a bit) - it's accurate, and this is a fantastic read!
The only reason it's using a low number of lines of code is because the script is leveraging other Linux tools to handle everything other than reading input and concatenating a file with it.
The tone of the article is also a bit inconsistent. The author starts by listing quotes about how software cannot be reasonably judged by the number of lines of code. But they do the same, except in the opposite direction.
And about his final statement: "with such a ridiculously small fraction of the code that one wonders why such complex systems even exist."
A big reason for this would be that those other apps are trying to be compatible with X number of platforms - devices, operating systems, browsers. This means that you can't simply "outsource" core functions of your software to implementations of the underlying OS, simply because they might not be there.
As an example, his script calls /usr/bin; AFAIK on MacOS, another UNIX OS, this directory isn't there, so the user needs to do some extra setup (symlink or edit the script) in order to work with it.
Anyway, it's a neat article for tech geeks, but the lessons learned can't really apply to any app that wants to appeal to some larger audience.
I thought the article was quite clear about intentionally not doing that and more so focusing on the leveraging of the neat abstractions that *nix provides and how these can easily compose into a powerful system.
Perhaps I'm being pedantic for no good reason. Kudos to the guy for finishing & explaining a project. I just find it a bit ironic for someone to oppose counting many lines of code, and also arguing for less. It would have been better if the article didn't mention this at all.