Hacker News Reader

Comment by throwaway984393 | Hacker News Reader

The rationale: https://hotdoglinux.com/PerlAndUseStrict/index.html

" Most tutorials about Perl will tell you to always 'use strict' or something to that effect. However, the general rule for HOT DOG Linux is to not 'use strict'. The reasoning behind this is that each Perl script should be as simple as possible. It should be simple enough to not need 'use strict'. If it gets to the point where the script would be easier to deal with if it did 'use strict', then that is an indicator that the script is too complicated and should be broken up."

I tried to come up with a comparison for this but failed. It's sort of like saying, "If you need to wear a helmet to do some activity, you should probably ......... break up the activity into three shorter activities ........."

View on HN

Since the smaller scripts run in separate processes, there is in fact a safety benefit to the break-up, which compensates in some way for the lack of strict. Processes are isolated; you know that a function call in one script will not misuse a function in another. Or that a global variable defined in one script can't be modified or accessed in the other. The scripts can only communicate via external mechanisms: command line arguments, environment variables, files/pipes/sockets, more rarely shared memory.

Unix was built using an extremely unsafe language. Yet it reached a decent level of reliability in just a few years, a lot of which was owed to the system applications being small programs isolated into separate processes.

Simple is beautiful, less is more.

You just move the complexity one layer up, at the composition of all those small utilities.

> You just move the complexity one layer up, at the composition of all those small utilities.

Out of curiosity, what would the name of the metric for measuring this tradeoff be? Average lines of code per script/program? Average scripts/programs to accomplish a given task?

I feel like it'd be really good to talk more about this tradeoff, e.g. having smart programs that do a lot but are bloated (OpenVPN, OpenSSL, Docker all come to mind) versus smaller programs that do less, but chain together (most GNU tools with the piping mechanism) and the extreme ends of this scale.

Yet, i don't even know how much research has been done into this, what the status quo is and what terms to even look up. It's like talking about the difference between a monolith application or a microservices application, an abstraction that would be applied to tasks and the ways to do them, much like we have SLoC or cyclomatic complexity in regards to reasoning about code (though neither is exactly perfect either).

Average number of interfaces/solution. If you only have 1 program, you have 1 interface (1 set of command-line arguments, 1 set of environment variables, 1 STDIN, 1 STDOUT). If you have 50 programs, you can have 50 interfaces. So, more interfaces, but.... more interfaces.

Composeability requires many different interfaces, but not every solution needs composeability.

Fair point, but doesn't that also kind of muddy the waters because interfaces also being a regular programming construct? E.g. you might have 50 libraries with 50 interfaces that still go in one very large program, no? And in practice that would be very different from chaining 50 different scripts/simple tools together.

That is false. When a small utility terminates, I'm assured that any file descriptors which it opened are closed, that any memory it allocated is gone, and that it didn't touch any data structures of the adjacent programs I'm composing it with. That's a whole lot of complexity that didn't move to the next layer.

Debugging complexity is reduced also because if something causes an abnormal termination, only the containing utility will die, not the entire composition.

How do you compose those small utilities?

War is peace, ignorance is bliss.

If a brick could fall on you and kill you, just use smaller bricks.

If a crib needs a gate it should be lower down.

Reply on news.ycombinator.com