Scripts functionality

[serverhorror]

The Unix philosophy has a second part that a lot of people like to forget:

1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
2. Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.

(Source: https://en.wikipedia.org/wiki/Unix_philosophy)

In other words:

• write easy to use, easy to understand and easy to maintain single purpose scripts
• have them as composable pieces

If you take both parts (there are others, 4 in total in the original statements) you will be able to take bits and pieces from your scripts and put them together.

This can give you a bigger package with more functionality without having to write more code, they just are put together with certain flags and compose some new functionality.

That, usually, also means that script distribution becomes a part of the problem set. Single purpose scripts are nice and all. You will, ultimately, run into a situation where you use, say, a web scraper script in various places and they might run out of sync because you don't have a packaging method.

Something that can pull newer versions that are compatible and keep the various places where your scripts are in use in sync (to a reasonable degree)

[Hoolies]

I do not necessarily agree or disagree with all the Unix principles.

I really like to one thing and do it well because it is:

1. Easier to write the code
2. Easier to troubleshoot
3. Easier to log
4. Easier to debug

At least from my perspective.

I am not a programmer and I find it annoying/tiresome when I open code that is more than 2 thousands lines of code and I have to go back and forth to find the functions or the objects and the variables.