Failing to draw lines between 'script' and 'program'

June 19, 2023

A while back on the Fediverse April King ran a poll on 'script' versus 'program'. In a reply, I fumbled around with my vaguely formed views:

I voted complex/simple but I think it's more complicated for me in practice. Something in a compiled language is always a 'program'; a large or complex thing is always a 'program', even for interpreted languages in a single file. Maybe a script mostly needs to depend on/use outside Unix programs, not internal things.

('A script' for me is separate from the Unix question of 'does it use a #! line and an interpreter to run', which is a technical issue that only sometimes matters.)

I'm not sure I fully believe what I posted any more, or even that I can clearly draw a distinction between 'script' and 'program' that feels right and is useful in practice. Personally, I think that all compiled things are programs, not scripts, and I probably call all of my Python code, even small ones, a 'program'. Is Linux's DKMS, famously written as several thousand lines of Bourne shell, a 'program' or a 'script'? I don't know. I've probably called it both at various times, but then some of the times I've called it a script I've probably meant that as short for 'a Bourne shell script', ie I was talking about the implementation language.

(On Unix, if you say 'script' people will generally assume it's a Bourne shell script instead of a 'script' in some other language, even in another shell. If you mean 'zsh script' or 'csh script', people expect you to say so explicitly. Although on Plan 9, 'script' probably means 'rc script', since Plan 9 didn't really have a Bourne shell.)

Some powerful Unix utilities provide a great opportunity to debate things. I think of most awk things as 'a program', but I'm not sure what a complex block of sed is; both 'script' and 'program' seem not really right.

At the same time there are definitely things I think of as 'scripts' and not 'programs', even if they contain some relatively complex logic. One example of this is my Bourne shell script for reporting Linux cgroup memory usage, which did a relatively sophisticated (and slow) job of reformatting information from a bunch of files. I never thought of that as a program, although my Python rewrite definitely is a program and not a script (to me). Possibly this is my Unix bias showing, where I'm inclined to think of things written in shell (Bourne or otherwise) as 'scripts' and things in most other languages 'programs'.

PS: Another great area of debate is code written to extend other programs. Are Emacs Lisp things 'scripts', 'programs', or something else entirely (I suspect that Emacs people have their own term for this and would reject both 'script' and 'program)? Vim has a 'script' language for writing plugins and other things, but I don't know if people call things written in it 'scripts'. In general it feels like what you could call 'extension scripts' are a different thing than 'scripts', even if they both use the same word.

(In summary, computing terminology is fun. For a certain sort of fun.)

Comments on this page:

By Michael at 2023-06-20 06:44:04:

If something written in sed is not really either a script nor a program, then what is something written in XSLT?

In principle, the two solve much the same problem: they are optimized for taking an input and relatively arbitrarily transforming it into some other (generally largely similar) output.

And a lot of my use of awk boils down to awk -F${sep} '{print $n}'. (For which in most situations I probably could use cut -d${sep} -f$n or something very similar to that. For some reason reaching for awk just happens more naturally for me.) Is that a script or a program? It almost certainly doesn't rise to the level of being copyrightable, or a lot of people will be in trouble. :-)

A script is a type of program. There's a bit of a distinction without a difference here, where the reality is more of a subset/superset relationship or at least a Venn diagram.

By Ian Z aka nobrowser at 2023-06-20 18:52:23:

Emacs is interesting because (unlike vim, I think) it doesn't really have a way to interpret input line by line, not even in the `batch` mode. You cannot run

 emacs --batch < foobar.el

emacs just ignores its stdin in the batch mode, and always uses it for interactive command input otherwise. So the closest you can get is

 IFS='' ; emacs --batch --eval `cat foobar.el`

To me, that makes emacs feel more like a compiler of elisp, amd less like an interpreter.

By informatimago at 2023-06-21 05:10:27:

The distinction I make between script and program is this:

the semantics of a script is contextual and dynamic
it depends on what executed earlier in the script.

on the other hand, the semantics of a program is context-free and lexical
you can understand the meaning of any part of the program, without having to execute any other part of the program.

I use this distinction, because by experience, we can have both situations using the same programming language. bash programs can be compiled. C programs can be interpreted. perl or lisp can be used to write either programs or scripts. (think perligata as the ultimate script).

Remember that the semantics of languages are independent of whether a given implementation of the language uses compilation and execution of compiled code, or interpretation (a lot of lisp implementations actually can do both!). Of course, when the language provides metalinguistic features, the risk of writing scripts is heightened. But even with the bare minimum, eg. redefinition of functions, can let you write scripts instead of programs.

Now, why scripts matter? Scripts are useful when you want to write some code that has to run in wildly different environments. Then the script must adapt to the environment it works in, and therefore we cannot predict the semantics of all the code, before running it, and establishing an interface with the actual running environment. On the other hand, when you have a run-time environment that is more precisely specified, then you can write programs.

Again, this is unrelated to the language. You can have bash programs, and you may have bash scripts.

By smorrow at 2023-06-22 18:32:10:

Something is 'a script' when all it does is run the same commands you would have run at the interactive prompt.

So bash and edbrowse scripts, for instance, are scripts.

At least, that's what I want script to mean. I don't really use it that way - 'Perl scripts', for instance, are not automations of any user-facing program.

Written on 19 June 2023.
« Link: The Difference Between Root Certificate Authorities, Intermediates, and Resellers
Having non-x86 machines makes your life harder, especially in a mixed setup »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Jun 19 22:46:36 2023
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.