"No, blue is definitely the better color for nuclear power station bike sheds".
It's all programs. Yes, even that one-liner.
Viewed from the right (or wrong) level of abstraction, everything that can be called a program, can be called a script, and vise-versa.
But the most important thing about this discussion, is that it's utterly unimportant. Like, what kind of decisions are made based on whether something is a script or a program?
JavaScript is interpreted and then compiled and optimized. If you're writing TypeScript, that's just converting it into JavaScript.
At the end of the day, a JavaScript program is delivered as text to be interpreted at runtime. A .NET C# .exe or .dll is not. Therefore, one is a script, the other is not.
I think of scripts as a sub-type of program; it is more appropriate to contrast it to a library, such that the intent changes a few expectations about how the program is built and maintained.
A script is specifically a program intended to perform a user process.
Scripts may be maintained by the "user" who has knowledge of the process, rather than the domain or software engineering. Things like style guides don't matter for a script if just needs to gets the job done. They may be messy and easier to replace than refactor if the process or environment change.
In Python I also make the distinction that a script (can) use hyphens in the name, which can be executed, e.g. `python do-thing.py`, but can't be imported through a typical `import` statement (because they generally shouldn't be).
As you say, this isn't really _important_. Scripts _can be_ well written and follow engineering principles. I just use this distinction to recognize the need for these "fast and loose" programs, where there's more emphasis on making a thing happen than maintaining the code.
By saying, "This is a script," I'm really saying, "I don't expect to put a lot of energy into it."
The distinction between script and program is a legacy of how a lot of software worked 30 years ago.
Compiled systems languages were fast, but required slow, AOT compilation, often had poor interactivity, and dealing with aggregate types (including strings) was unwieldy.
So you wrote your libraries in programming languages, and you glued them together with scripting languages.
Yes, the difference made sense decades in the past when a script was a collection of commands that were followed like a written script, and a program was general-purpose code that was executed. But now, scripting languages have morphed into general-purpose programming languages and the distinction doesn't make much sense. E.g. JavaScript, Perl, Python, Lua, Ruby.
But I personally use the word script to refer to small (in term of code) programs. That are very task specific, not necessarily robust to errors, with a lot of hard coded assumptions, and most often in some relatively slow interpreted language.
Best practice I've seen: Let the difference be determined by local ground rules ( https://en.wikipedia.org/wiki/Ground_rules ), and set those rules so as to best facilitate accurate & concise communications within your organization.
IME, a script is a custom utility and generally small (maybe <500 lines). It's a go-between for other programs, getting its input by running another program (like ps or netstat), or it reads the state of the O/S (like /proc), or it reformats data for output or to prepare input to another program. Scripts are almost always written in an interpreted language (and their execution time is rarely important), and usually they don't handle faults robustly.
I think it's a meaningful distinction, because it's about intent. When I write a "script", it's more about being quick and easy to write (so "scripting languages" appeal), easy to read (that is, more like a DAMP test with lots of comments), and something that's going to live in one file. "Programs" are more about being higher performance, maintainable, extensible, DRY, etc. The intent matters mainly because of the lifetime of the code - the scripts are a nightmare to maintain if they get huge and live for years. The programs are more work upfront and often harder to quickly understand.
- Intended to automate a single well-defined process
- With no or minimal interactivity beyond command-line parameters.
In essence, a script is just a formalization of a task a user is trying to accomplish. It could be replaced by a well-trained monkey and primarily serves to avoid making mistakes when trying to execute it again and again.
I've written "scripts" that do things like create a user, run migrations, or do some processing on a file that pull in either or both of 3rd-party libraries or other code I wrote (ie. db models). So the "contained in a single file" for me isn't a hard requirement. I do think the rest of your points are accurate though. I'd also add that a script runs until the task is done, and no longer. Whereas you may have other programs, like web services or queue workers, that continue running and doing their tasks.
I think I've tended to think of scripts as documents. Typically when I use it I'm describing to another programmer the name of a file (document), as in "Use the calculator(.py) script" or what have you.
While I'm sure I've used the term interchangeably with program as others have mentioned, I tend to use it to identify the names of specific language files. And as others have mentioned, they're all more or less programs when it comes down to it.
I once saw a CS student ask for homework help on Reddit, with a question premised on the course material's attempted formalization of "high level" and "low level" programming languages as a partial ordering based on machine-translatability from one language to the other. The terms "level n" and "level n-1" were being bandied about. Another instance of adding confusion by trying to sharpen the definition of terminology that is probably most useful when it remains fuzzy.
Like all words, 'script' and 'program' mean whatever you arbitrarily feel like they should mean in the moment. There are no lines until there is use, and what lines may exist during that use can only be determined at the time of use. And at the next time of use, things could be completely different. Some times there may be lines, other times there may not be.
If you need to draw lines between two things, 'script' and 'program' may be tools you can use to communicate that. Or maybe not. Indeed, there is a lot of guess work involved in communication, and it can take some trial and error to find the right tools to accurately reach the intended audience.
Is the distinction useful? Like, am I going to lead someone down the wrong path suggesting they write a "script" to solve their problem, instead of a "program"?
At most I feel a script is a kind of program, maybe a short or unsophisticated one. Beyond that, I never think about this.
For me, the difference is the notion of "procedure" :
* scripts are a sequence of of parametrized commands. It's the list of interactives shell commands stored in a text file
* programs are everything else : as soon as there's a function/procedure definition inside a file, it's a program
In a way, it's all about control flow and recursivity : script can't be recursives (like a function calling itself) so it's usually less complex
It might seem arbitrary but we've all seen :
* bash "scripts" with functions inside the script is a program (but a bash script calling another bash script is not, as the called bash script is just considered a command)
* python "programs" without any procedure are actually scripts
In the end, scripts are just some kind of macro, used to repeat some finite sequence of actions (with parameter if necessary). They don't provide enough "power" to be compared to a program... and because of that, they are easier to read, modify
You have interpreted programs and compiled programs.
A script is a series of instructions to a program - a script of actions for it to follow.
I'm fairly sure that you do get scripts that are compiled and linked to the application they are controlling, but mostly they are interpreted.
I think the difference can be useful in terms of addressing different software/DX needs. For example, scripts and programs tend to have very different maintenance, dependency management, packaging, publishing, etc needs.
You see this a lot in the Python ecosystem, where Python is used extensively for simple scripts that just need to calculate one thing and then tend not to get maintained, but also for larger software projects that will be continually updated and maintained over time. Currently, Python packaging is in a pretty poor shape, and it doesn't work well for a lot of people in different ways, but if we look at software on a kind of script/program continuum, we can group people's needs into two rough camps. That sort of grouping and categorisation helps make it easier to find solutions: rather than solving the problems of ever single Python developer ever, we can now reduce the situation down to two problems: that of the script developer and that of the program developer.
This is of course just an example - in practice, there might be more categories that are worth making here, and those categories may well have sub categories that are worth exploring. But I think these sorts of divisions can often be useful.
That said, I've heard the advice before that categories are only useful if they're being used additively - that is, a category is useful if we're more interested in what we can put into the category than what we can exclude from it. So with the Python example, this is useful if we're trying to build categories of code types that tell us something about how our tools are being used. But if we're only interested in marking code as being "script" in order to exclude them from our more 'advanced' category of "program", then we may as well give up.
I strongly suspect however, for people who are not primarily concerned with practical things perhaps, unrestrained pondering is a big driver of new discovery.
Next we can argue about the value of 4 / 2 * 2, and then on wednesday we can have a fight about the clearcut and important distinction between “nerd” and “geek”
I work with people who write “scripts” in Go. Pretty sure these terms were once important—a program was assembled. A script was a set of things you’d otherwise do by hand (eg run these 30 commands).
“Scripting languages” that created more abstraction power blurred the lines. But, I still think a script is something you’d lazily do, otherwise by hand, without the script
This may be a definition with several edge cases, but I always thought of a program as something that was compiled and run, whereas a script was information you fed into a running program.
I think this debate, also known at the "Ousterhout dichotomy" [1], has been moot for many years. (I believe, though, it was relevant when initially stated, i.e. ni 1998).
>The dichotomy was fully set out in Ousterhout (1998), though Ousterhout had drawn this distinction since at least the design of Tcl (1988), and had stated it publicly at various times. An early episode was "The Tcl War" of late September and October 1994, where Richard Stallman posted an article critical of Tcl, entitled "Why you should not use Tcl",[2] to which Ousterhout replied with an articulation of his dichotomy:[3]
>I think that Stallman's objections to Tcl may stem largely from one aspect of Tcl's design that he either doesn't understand or doesn't agree with. This is the proposition that you should use two languages for a large software system: one, such as C or C++, for manipulating the complex internal data structures where performance is key, and another, such as Tcl, for writing small-ish scripts that tie together the C pieces and are used for extensions.
>dasht on April 14, 2010 | parent | context | favorite | on: Guile - The Failed Universal Scripting Language
>Huh. Well, that's me (Tom Lord). So, what can I add here for HN?
>Some of the comments talk about Andy Wingo's good work and leadership in recent years. I agree. Of course, Guile was once my baby, long ago, complete with sleepless nights and other trappings of nervous parenthood. Consequently, I see almost all of the big technical changes made to Guile recently as The Wrong Way. But that's a purely personal, emotional reaction; objectively I see that he's doing good work.
>Guile failed / stalled for a few years there. It's a bit hard to talk about why. I'll say a few words about it and also point to a link with a an alternative telling of the same tale.
>Guile got started after some earlier, failed attempts to write a Scheme extension language library for Scheme. There were two earlier attempts that I know of: one called "revoc" (read it backwards) and the other had no name but happened as part of an early GNU spreadsheet project.
>I went to work for a start-up that, then, had something like 30 employees. It was an unusual start-up for its day for the software part of all of their products was free software. The Linux kernel didn't exist when the company was founded and it barely existed when I first started at that firm.
>The firm was Cygnus, of course. Back then it was called "Cygnus Support".
>Cygnus got it into its collective head, for a short period of time, to build a general purpose user interface toolkit for writing GUI apps -- and to make this GUI toolkit Scheme-based and to write GUI apps that were architecturally similar to GNU Emacs, but with fancier graphics and interaction. Building that thing was to be my job.
>To save time I started with Aubrey Jaffer's Scheme implementation called SCM. I forked SCM and began radically modifying it to make it more useful as a library and to add various desirable features. I wrote a C library for Guile to give it a generic window system interface, providing an X11 implementation of that library. Towards the end, I had much of the heavy lifting of the toolkit done and perhaps another 6-12 months before a real product. In my toolkit I even had a basic Emacs-like program except with features that Emacs lacked at the time like support for multiple-font text and proportionally spaced fonts. It was kind of neat because nearly all of the redisplay code, and all of the code for "text widgets", was written in Scheme - and yet performed reasonably well on even the slow machines of the time. It was a very "hackable", fun, toolkit.
>Alas, there were political problems. The sales staff at Cygnus, especially, were displeased that the project was taking so long: they had been hoping to have GUIs to show at trade-shows mere months after I started. The famou...
A script is mostly human-readable text that is A) intended to be consumed by an interpreter, B) short/simple enough for one person to create/maintain it without having to consider it a second job, and C) where the interpreter facilities B.
I wouldn't use the term "script" to describe binaries of any type.
A module or plugin is a bit of binary code that can be inserted into a larger body of code, either during startup or while running.
Program is the ambiguous term, sort of like application and operating system. I would say anything executed--or possible to be executed--within a process's binary image is a program. So a program would consist of an executable, plus any modules/plugins, but not non-executed/interpreted data. A script requires a program (the interpreter) to run - after all you launch the interpreter (explicitly or implicity) and not the script when you're "running" a script.
We have the term "bytecode" to describe non-human-readable data that is intended to be consumed by an interpreter.
Human-readable text that is A above, but not B or C ... I tend to use "program" for that - I don't know a better thing to call it.
All scripts are programs but not all programs are scripts.
A script is a program which includes its source and where the compile step (if it exists) is abstracted from the user, and where the source is distributed with the program.
Traditionally these are things which are run with a shebang first line, but that's not a strict requirement.
For example, if I distribute foo.java and can run it directly via "java foo.java" then foo.java is a script. (Java 11 added support for this.) If I have to run javac first and distribute only the resulting class, it's not a script.
I think the definitions are useful here - a script is part of a program, and a program gives structure to a large script or to many loosely related scripts (I think of the paper program you receive at a performance). Thus everyone is right, a script is a program (with just one script), and a program is just a large script, or a collection of many scripts.
Much of this wording likely derives from plays and performances (also see Actors in computer science):
[0] Program (https://www.merriam-webster.com/dictionary/program): I think the 2nd or 3rd definition is best here (as the later definitions actually refer to computer programs, but don't cut to my proposed etymology) - "2. a: a brief usually printed outline of the order to be followed, of the features to be presented, and the persons participating (as in a public performance)".
[1] Script (https://www.merriam-webster.com/dictionary/script): I think 1c2 again is most relevant here, as it is likely the root of its usage in computers - "1. c (2): the written text of a stage play, screenplay, or broadcast... specifically: the one used in production or performance".
53 comments
[ 2.4 ms ] story [ 129 ms ] threadIt's all programs. Yes, even that one-liner.
Viewed from the right (or wrong) level of abstraction, everything that can be called a program, can be called a script, and vise-versa.
But the most important thing about this discussion, is that it's utterly unimportant. Like, what kind of decisions are made based on whether something is a script or a program?
"Script" is more accurately a descriptor of the language and runtime. Typically meaning it is interpreted at runtime versus complied at build time.
Every script is a program.
In any case it's not a meaningful distinction.
At the end of the day, a JavaScript program is delivered as text to be interpreted at runtime. A .NET C# .exe or .dll is not. Therefore, one is a script, the other is not.
This is a script:
print("This line will be printed.")
Without runtime, it does nothing.
A script always needs a runtime.
A script is specifically a program intended to perform a user process.
Scripts may be maintained by the "user" who has knowledge of the process, rather than the domain or software engineering. Things like style guides don't matter for a script if just needs to gets the job done. They may be messy and easier to replace than refactor if the process or environment change.
In Python I also make the distinction that a script (can) use hyphens in the name, which can be executed, e.g. `python do-thing.py`, but can't be imported through a typical `import` statement (because they generally shouldn't be).
As you say, this isn't really _important_. Scripts _can be_ well written and follow engineering principles. I just use this distinction to recognize the need for these "fast and loose" programs, where there's more emphasis on making a thing happen than maintaining the code.
By saying, "This is a script," I'm really saying, "I don't expect to put a lot of energy into it."
I couldn't answer yes for any point, so considering them the same it's simpler.
It depends what you are doing and who you are working with, I suppose.
Executables (binaries) run directly.
Some code requires an interpreter to run.
Really important to the OS and those who want to run the application, as you need the right interpreter for the second case.
Compiled systems languages were fast, but required slow, AOT compilation, often had poor interactivity, and dealing with aggregate types (including strings) was unwieldy.
So you wrote your libraries in programming languages, and you glued them together with scripting languages.
But I personally use the word script to refer to small (in term of code) programs. That are very task specific, not necessarily robust to errors, with a lot of hard coded assumptions, and most often in some relatively slow interpreted language.
Scripts are conveniences; hacks.
- A program
- Contained in a single file
- Distributed in source code form
- Intended to automate a single well-defined process
- With no or minimal interactivity beyond command-line parameters.
In essence, a script is just a formalization of a task a user is trying to accomplish. It could be replaced by a well-trained monkey and primarily serves to avoid making mistakes when trying to execute it again and again.
While I'm sure I've used the term interchangeably with program as others have mentioned, I tend to use it to identify the names of specific language files. And as others have mentioned, they're all more or less programs when it comes down to it.
This is not to say that it is a pointless distinction, but trying to make it a sharp distinction probably is.
If you need to draw lines between two things, 'script' and 'program' may be tools you can use to communicate that. Or maybe not. Indeed, there is a lot of guess work involved in communication, and it can take some trial and error to find the right tools to accurately reach the intended audience.
At most I feel a script is a kind of program, maybe a short or unsophisticated one. Beyond that, I never think about this.
* scripts are a sequence of of parametrized commands. It's the list of interactives shell commands stored in a text file
* programs are everything else : as soon as there's a function/procedure definition inside a file, it's a program
In a way, it's all about control flow and recursivity : script can't be recursives (like a function calling itself) so it's usually less complex
It might seem arbitrary but we've all seen :
* bash "scripts" with functions inside the script is a program (but a bash script calling another bash script is not, as the called bash script is just considered a command)
* python "programs" without any procedure are actually scripts
In the end, scripts are just some kind of macro, used to repeat some finite sequence of actions (with parameter if necessary). They don't provide enough "power" to be compared to a program... and because of that, they are easier to read, modify
But YMMV
And if I cannot answer I just stop pondering the question altogether.
You see this a lot in the Python ecosystem, where Python is used extensively for simple scripts that just need to calculate one thing and then tend not to get maintained, but also for larger software projects that will be continually updated and maintained over time. Currently, Python packaging is in a pretty poor shape, and it doesn't work well for a lot of people in different ways, but if we look at software on a kind of script/program continuum, we can group people's needs into two rough camps. That sort of grouping and categorisation helps make it easier to find solutions: rather than solving the problems of ever single Python developer ever, we can now reduce the situation down to two problems: that of the script developer and that of the program developer.
This is of course just an example - in practice, there might be more categories that are worth making here, and those categories may well have sub categories that are worth exploring. But I think these sorts of divisions can often be useful.
That said, I've heard the advice before that categories are only useful if they're being used additively - that is, a category is useful if we're more interested in what we can put into the category than what we can exclude from it. So with the Python example, this is useful if we're trying to build categories of code types that tell us something about how our tools are being used. But if we're only interested in marking code as being "script" in order to exclude them from our more 'advanced' category of "program", then we may as well give up.
I strongly suspect however, for people who are not primarily concerned with practical things perhaps, unrestrained pondering is a big driver of new discovery.
“Scripting languages” that created more abstraction power blurred the lines. But, I still think a script is something you’d lazily do, otherwise by hand, without the script
See for instance https://www.youtube.com/watch?v=KZ8u_sWT9Ls or a presentation I gave 10 years ago [2].
[1]: https://en.wikipedia.org/wiki/Ousterhout%27s_dichotomy
[2]: https://speakerdeck.com/sfermigier/four-python-pains-may-201...
>The dichotomy was fully set out in Ousterhout (1998), though Ousterhout had drawn this distinction since at least the design of Tcl (1988), and had stated it publicly at various times. An early episode was "The Tcl War" of late September and October 1994, where Richard Stallman posted an article critical of Tcl, entitled "Why you should not use Tcl",[2] to which Ousterhout replied with an articulation of his dichotomy:[3]
>I think that Stallman's objections to Tcl may stem largely from one aspect of Tcl's design that he either doesn't understand or doesn't agree with. This is the proposition that you should use two languages for a large software system: one, such as C or C++, for manipulating the complex internal data structures where performance is key, and another, such as Tcl, for writing small-ish scripts that tie together the C pieces and are used for extensions.
More on The TCL War:
https://news.ycombinator.com/item?id=1266032
>dasht on April 14, 2010 | parent | context | favorite | on: Guile - The Failed Universal Scripting Language
>Huh. Well, that's me (Tom Lord). So, what can I add here for HN?
>Some of the comments talk about Andy Wingo's good work and leadership in recent years. I agree. Of course, Guile was once my baby, long ago, complete with sleepless nights and other trappings of nervous parenthood. Consequently, I see almost all of the big technical changes made to Guile recently as The Wrong Way. But that's a purely personal, emotional reaction; objectively I see that he's doing good work.
>Guile failed / stalled for a few years there. It's a bit hard to talk about why. I'll say a few words about it and also point to a link with a an alternative telling of the same tale.
>Guile got started after some earlier, failed attempts to write a Scheme extension language library for Scheme. There were two earlier attempts that I know of: one called "revoc" (read it backwards) and the other had no name but happened as part of an early GNU spreadsheet project.
>I went to work for a start-up that, then, had something like 30 employees. It was an unusual start-up for its day for the software part of all of their products was free software. The Linux kernel didn't exist when the company was founded and it barely existed when I first started at that firm.
>The firm was Cygnus, of course. Back then it was called "Cygnus Support".
>Cygnus got it into its collective head, for a short period of time, to build a general purpose user interface toolkit for writing GUI apps -- and to make this GUI toolkit Scheme-based and to write GUI apps that were architecturally similar to GNU Emacs, but with fancier graphics and interaction. Building that thing was to be my job.
>To save time I started with Aubrey Jaffer's Scheme implementation called SCM. I forked SCM and began radically modifying it to make it more useful as a library and to add various desirable features. I wrote a C library for Guile to give it a generic window system interface, providing an X11 implementation of that library. Towards the end, I had much of the heavy lifting of the toolkit done and perhaps another 6-12 months before a real product. In my toolkit I even had a basic Emacs-like program except with features that Emacs lacked at the time like support for multiple-font text and proportionally spaced fonts. It was kind of neat because nearly all of the redisplay code, and all of the code for "text widgets", was written in Scheme - and yet performed reasonably well on even the slow machines of the time. It was a very "hackable", fun, toolkit.
>Alas, there were political problems. The sales staff at Cygnus, especially, were displeased that the project was taking so long: they had been hoping to have GUIs to show at trade-shows mere months after I started. The famou...
I wouldn't use the term "script" to describe binaries of any type.
A module or plugin is a bit of binary code that can be inserted into a larger body of code, either during startup or while running.
Program is the ambiguous term, sort of like application and operating system. I would say anything executed--or possible to be executed--within a process's binary image is a program. So a program would consist of an executable, plus any modules/plugins, but not non-executed/interpreted data. A script requires a program (the interpreter) to run - after all you launch the interpreter (explicitly or implicity) and not the script when you're "running" a script.
We have the term "bytecode" to describe non-human-readable data that is intended to be consumed by an interpreter.
Human-readable text that is A above, but not B or C ... I tend to use "program" for that - I don't know a better thing to call it.
- a script is written by the user for his own needs
- a script is written in a dynamic language like bash, python, perl...
- a script is not intended to be maintained, it will be thrown away once it has done its job
- a script only exists in source form
- a script is only one file, usually a small one
- a script starts with #!
- scripts automate user actions, like shell commands or button clicks
- scrips are written by people whose main job is not programming
- ...
Now pick your lines to draw
A script is a program which includes its source and where the compile step (if it exists) is abstracted from the user, and where the source is distributed with the program.
Traditionally these are things which are run with a shebang first line, but that's not a strict requirement.
For example, if I distribute foo.java and can run it directly via "java foo.java" then foo.java is a script. (Java 11 added support for this.) If I have to run javac first and distribute only the resulting class, it's not a script.
That's my definition anyway.
Much of this wording likely derives from plays and performances (also see Actors in computer science):
[0] Program (https://www.merriam-webster.com/dictionary/program): I think the 2nd or 3rd definition is best here (as the later definitions actually refer to computer programs, but don't cut to my proposed etymology) - "2. a: a brief usually printed outline of the order to be followed, of the features to be presented, and the persons participating (as in a public performance)".
[1] Script (https://www.merriam-webster.com/dictionary/script): I think 1c2 again is most relevant here, as it is likely the root of its usage in computers - "1. c (2): the written text of a stage play, screenplay, or broadcast... specifically: the one used in production or performance".