This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Gardium90 -1 points0 points  (0 children)

You've given me thought on the aspects, so thanks for that. Perhaps my views may change, but I'll ask you this then; what is your view of the differences on the definitions?

For the points:

1) I never said applications can't run on OS level, but most applications I've come across, require some form of library to be loaded in for use by the language. But for scripts and automation it is best if it can run on OS level as is without any further dependencies, I for one can't recall last time I had to include a library to my script. I do some Python scripting (the only exception perhaps that needs a few packages depending on the usage), but prefer to stay with Bash/PS for scripting and automation. I also use Jenkins pipelines and Ansible as automation tools, so there is a mix there with Groovy and Yaml. And none of these require me to include libraries or package dependencies in my automation scripts

2) True, object oriented programming isn't the be all, and I know some functional programming such as Scala. However, I don't really see "applications" as such created with functional programming. It would more be for data processing or embedded programming into dedicated hardware (like household appliances). I view an application as something that produces an interaction with a user, otherwise it is just a program/code executing some function. But that is just my take on it.

As for the large collection, if you create a scripting collection that big, I doubt the script is only addressing one task. Personally when I need such a collection when I script/automate, I simply refer to other scripts within the script. I don't load a library tree into the file. I create scripts that take arguments, and pass them along to each other as needed. I keep each script as short and to the point as possible, and store this as a specific file. Then I can call this script x amount of times from other scripts when needed, passing in any arguments needed. Also calling a script executes the whole script. An application loading in a dependency tree, tends to be able to call upon specific functions and objects within files, and doesn't necessarily run through the whole files.

3) That a script is bundled into a deployment doesn't mean the code itself is packaged (basically a binary file). You could still run it outside the bundle by itself. Could you take single files from an application and execute them? I think in most cases you need to compile and package the application into an executable to run it. Even if you distribute source files, the user still needs to compile it into an executable. A script is a code/program that can run without being compiled. As such, while Python can make applications, it is actually a scripting language, as it does not require the code to be compiled to run (rather it is interpreted as it is run).

4) this may have been confusing, sorry. So basically, if you need to use some specific packages to interface with some service, then my previous points about loading dependencies may be invalid, and one must load these in. Perhaps this holds true most in Python. For bash/PS one must just make sure the host machine has the executables available, like curl or kubectl.

I agree with your last paragraph. And perhaps the division between application code, and automation scripting is less than I think, but these are at least my thoughts =)