Failing to draw lines between ‘script’ and ‘program’(utcc.utoronto.ca)
utcc.utoronto.ca
Failing to draw lines between ‘script’ and ‘program’
https://utcc.utoronto.ca/~cks/space/blog/programming/ScriptVersusProgram
53 comments
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."
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."
Does this classification give any value?
I couldn't answer yes for any point, so considering them the same it's simpler.
I couldn't answer yes for any point, so considering them the same it's simpler.
Does being able to say
It depends what you are doing and who you are working with, I suppose.
I have a labrador.
I have a dog.
It depends what you are doing and who you are working with, I suppose.
Agree.
"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.
"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.
A script is code, without runtime it's just text
This is a script:
print("This line will be printed.")
Without runtime, it does nothing.
This is a script:
print("This line will be printed.")
Without runtime, it does nothing.
Without libc, most compiled programs will struggle to run as well. That "print" is a human readable command in Python is besides the point.
So, we need to rename JavaScript to JavaProgram since it is compiled instead of interpreted these days.
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.
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.
That's just what Kyle Simpson says.
In any case it's not a meaningful distinction.
In any case it's not a meaningful distinction.
It's easier to change a script than a program.
It's easier to understand a script than a program (of the same complexity)
> what kind of decisions are made based on whether something is a script or a program?
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.
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.
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.
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.
Personally, I'd say that a script is:
- 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.
- 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.
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.
Sometimes when pondering a question I stop to think: "why is this important?"
And if I cannot answer I just stop pondering the question altogether.
And if I cannot answer I just stop pondering the question altogether.
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.
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.
That's very practical.
I strongly suspect however, for people who are not primarily concerned with practical things perhaps, unrestrained pondering is a big driver of new discovery.
I strongly suspect however, for people who are not primarily concerned with practical things perhaps, unrestrained pondering is a big driver of new discovery.
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.
At most I feel a script is a kind of program, maybe a short or unsophisticated one. Beyond that, I never think about this.
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.
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.
It is an example of the sorites paradox: https://plato.stanford.edu/entries/sorites-paradox/
This is not to say that it is a pointless distinction, but trying to make it a sharp distinction probably is.
This is not to say that it is a pointless distinction, but trying to make it a sharp distinction probably is.
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.
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
But YMMV
* 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
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).
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...
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...
>History
>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 famous "Tcl Wars" happened and that led to some political infighting within Cygnus. Cygnus was seeking a next round of VC funding and there was pressure to cut the Guile project from the budget. Most annoyingly, my boss at the end showed me a contract he'd negotiated to help fund Guile work and asked me to approve it. I felt that the contract had some severe problems and would need to be fixed before I could agree to it - he'd negotiated it without any input from me. The next day he signed the contract. About a week later I felt duty bound to quit (because of the contract and because of some bullshit issues about my working remotely). The demise of the Guile project at Cygnus was a profoundly unpleasant experience.
>Quitting, at that time, was a somewhat crazy step to take. We parted on less than friendly terms. I had been accustomed to job searching in the Silicon Valley, back in those days, this way: you call a few recruiters; you fax or email them your resume; you have phone calls for a few days; you get some interviews; you take your next job. The Valley was, truly, the Garden of Earthly Delights for a hacker in those boom years. This time was different. I spoke to several otherwise decent recruiters who all quickly, and to my surprise, made it clear to me that each and every one had been warned away from me by people close to Cygnus.
>Some people will tell you that the Silicon Valley elites back then did not secretly blacklist people from employment. Those people are variously mistaken or lying. Get on the wrong side of a couple of those elites and, in my experience - that was it. You're out. The U-Haul place is down the street. On-ramp to highway 80 is over there. Get out of town. See you in the next life.
>Shortly after that I had to abandon my status as the GNU Guile maintainer (at status conveyed by the FSF, not Cygnus) for financial reasons: I was busy working out some way to keep a roof over my family's head. The project was taken over by one of the "revoc" developers about whose work on it, during that period, I have nothing nice to say.
>Within those next few years the Linux kernel's foothold got quite strong. The FSF greatly diminished its efforts to build a "complete GNU system" and, rather than making sure lots of interactive applications were extensible in the style of Emacs, the GNU project became more of a follower than a leader.
>In those same next few years, a faction of people close to Cygnus who had first hostilely forked GCC then forced its maintainership away from the FSF.
>Overall, the FSF became far less proactive at software development and the original "vision" of a lisp-centric improved version of unix fell by the wayside. One of the last big actions from GNU was to endorse an alternative GUI app framework - GNOME - on the grounds that at least it didn't have the licensing problems that, at the time, KDE had. Any remaining hope of directly developing the lisp-style environment we'd started out to build evaporated right there.
>Here is a different version of some part of the same story (also as told by me, and why should you believe me? :-)
http://basiscraft.com/0800-0100-the-tcl-war.html
>(Where did I go after Cygnus? After several agonizing months I landed a job working remotely for an R&D group at UUNET. That was a gig that went very well for a couple of years. You know, until it was suddenly revealed that the firm was bankrupt and that it's CEO was being arrested. I tell ya', I can't catch a break. ;-)
https://news.ycombinator.com/item?id=12027092
>DonHopkins on July 3, 2016 | parent | context | favorite | on: The Tcl War (1994)
>Around the time leading up to the TCL war, Lua was peacefully and quietly born in a manger at the Pontifical Catholic University of Rio de Janeiro, Brazil: "In 1993, the only real contender was Tcl, which had been explicitly designed to be embedded into applications. However, Tcl had unfamiliar syntax, did not offer good support for data description, and ran only on Unix platforms. We did not consider LISP or Scheme because of their unfriendly syntax. Python was still in its infancy. In the free, do-it-yourself atmosphere that then reigned in Tecgraf, it was quite natural that we should try to develop our own scripting language ... Because many potential users of the language were not professional programmers, the language should avoid cryptic syntax and semantics. The implementation of the new language should be highly portable, because Tecgraf's clients had a very diverse collection of computer platforms. Finally, since we expected that other Tecgraf products would also need to embed a scripting language, the new language should follow the example of SOL and be provided as a library with a C API."
http://www.lua.org/doc/hopl.pdf
https://news.ycombinator.com/item?id=17061858
>And with that diplomatically worded message, RMS kicked of The Infamous TCL War.
>That was Stallman's response to Sun bombastically pushing TCL as the official scripting language of the web, BEFORE Live Oak / Java was a widely known (or evangelized) thing.
>At the point anybody started talking about a Java/TCL bridge, it was already all over for TCL becoming the "ubiquitous scripting language of the Internet".
>Sun's unilateral anointment of TCL as the official Internet scripting language trigged RMS's "Why you should not use Tcl" message, which triggered the TCL War, which triggered Sun to switch to Java.
>After the TCL war finally subsided, Sun quietly pushed TCL aside and loudly evangelize Java instead. The TCL community was quite flustered and disappointed after first winning the title "ubiquitous scripting language of the Internet" and then having the title yanked away and given to Java.
>Any talk of bridges were just table scraps for TCL, the redheaded bastard stepchild sitting outside on the back porch in the rain, smoking a cigarette and commiserating with NeWS and Self.
>Tom Lord's description of what happened is insightful and accurate:
https://web.archive.org/web/20110102015130/http://basiscraft...
>The Infamous Tcl War
>[...] Mr. Ousterhout had, a few years prior, developed Tcl while on the faculty of UC Berkeley - mainly, I think, to have a handy tool for other research and only secondarily as an experiment in language design. And he topped it off with Tk. Tcl/Tk took off in a huge way. It was easy to understand. The source code, written in Mr. Ousterhout's methodical and lucid style, was a joy to read. At the time, about the most convenient option for developing a GUI to run on a unix system was to write C code against the Motif toolkit - an ugly, expensive, and frequently disappointing process. With Tcl/Tk in hand, people started handing out new "mini-GUIs" for this and that, like candy. Tcl/Tk started to find application in some rather intense areas, like, for example, the "control station" software for some oil rigs. It was a smash hit.
>Meanwhile, I don't think I'm letting too many cats out of the bag here, the informal Silicon Valley social network of well placed hackers were quietly and unofficially circulating some very interesting confidential whitepapers from Sun Microsystems. One of their researchers, a fellow called Mr. Gosling, had dusted off a language he'd once led the design of called "Oak". Oak was originally intended for use in embedded systems. Its basic premise was that devices ought to be Turing complete and hackable, whenever possible. Oak's approach to statically verifiable byte-code comes from that origin. Mr. Gosling came out of Carnegie Mellon University and the attiude behind Oak was popular there. As one grad student had quipped a few years earlier: "If a light switch isn't Turing Complete I don't even want to touch it."
>In light of the rising star of web browsers, the folks at Sun conceived the notion of offering up a derivative of Oak to serve as the extension language for browsers. (It is probably worth mentioning here that Mr. Gosling was earlier well known for making one of the very first unix versions of Emacs.) Oak was re-named "Java" and the rest of its history is fairly well known.
>I've read, since then, that up to around that point Brendan Eich had been working on a Scheme-based extension language for Netscape Navigator. Such was the power of the hegemony of the high level folks at Sun that the word came down on Mr. Eich: "Get it done. And make it look like Java." Staying true to his sense of Self, he quickly knocked out the first implementation of Mocha, later renamed Javascript. This phenomenon of Sun's hegemony influencing other firms turns out to be a small pattern, as you'll see.
>Mr. Ousterhout was hired by Sun (later he would spin off a Tcl-centric start-up). The R&D; team there developed a vision:
>Java would be the heavy-lifting extension language for browsers. The earliest notions of the "browser as platform" and "browser as Microsoft-killer" date back to this time. Tcl, Sun announced, was to become the "ubiquitous scripting language of the Internet". Yes, they really pimped that vision for a while. And it was "the buzz" in the Valley. It was that pronouncement from the then-intimidating Sun that led to the Tcl wars.
>Mr. Eich, bless his soul, brute-forced passed them, abandoning Scheme and inventing Javascript. [...]
https://news.ycombinator.com/item?id=29379272
>DonHopkins on Nov 29, 2021 | parent | context | favorite | on: CPython's main branch running in the browser with ...
>For Netscape in 1995, I believe Python would have been a better choice than JavaScript, but Lua would have been an even better choice, given how much smaller, simpler, and more efficient Lua is, and the eventual excellence of LuaJIT. (If only Lua indexed its array from 0 instead of 1...)
>But Python and Lua didn't "look like Java" enough for Netscape. [...]
https://news.ycombinator.com/item?id=30405409
>DonHopkins on Feb 20, 2022 | parent | context | favorite | on: Fengari – Lua for the Browser
>I wish Netscape had chosen Lua instead of bothering to invent JavaScript. Python would have also been much better than JavaScript, but Lua would have been perfect. But at least they didn't choose TCL, as Sun was pushing before they switched gears to Java after the Great TCL War. And personally, I would have preferred PostScript (which was the basis of NeWS, with a Smalltalk-like OOP system) or ScriptX (which was like Scheme or Dylan with "normal" infix syntax and a CLOS-like OOP system) to JavaScript.
>If all the time and effort and treasure that was wasted cobbling together JavaScript from scratch with all its naive unforced design flaws and security holes and interoperability issues -- and then everyone else pissing away so much effort working around and fixing subtle bugs in JavaScript code due to those terrible design flaws (cough cough "this" cough cough "equality") -- had been put into Lua instead, which was cleanly designed from the start by incredibly smart people who actually had a clue about what they were doing, the world would be a much better place.
>People who are that confused about equality shouldn't design programming languages:
https://dorey.github.io/JavaScript-Equality-Table/
>"All animals are equal, but some animals are more equal than others." -George Orwell, Animal Farm
[...]
https://news.ycombinator.com/item?id=31117713
>DonHopkins on April 22, 2022 | parent | context | favorite | on: The Birth of Tcl
>The Tcl War (1994) (vanderburg.org)
https://news.ycombinator.com/item?id=12025218
https://vanderburg.org/old_pages/Tcl/war/
>Why you should not use Tcl
https://wiki.tcl.tk/16730
[...]
>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 famous "Tcl Wars" happened and that led to some political infighting within Cygnus. Cygnus was seeking a next round of VC funding and there was pressure to cut the Guile project from the budget. Most annoyingly, my boss at the end showed me a contract he'd negotiated to help fund Guile work and asked me to approve it. I felt that the contract had some severe problems and would need to be fixed before I could agree to it - he'd negotiated it without any input from me. The next day he signed the contract. About a week later I felt duty bound to quit (because of the contract and because of some bullshit issues about my working remotely). The demise of the Guile project at Cygnus was a profoundly unpleasant experience.
>Quitting, at that time, was a somewhat crazy step to take. We parted on less than friendly terms. I had been accustomed to job searching in the Silicon Valley, back in those days, this way: you call a few recruiters; you fax or email them your resume; you have phone calls for a few days; you get some interviews; you take your next job. The Valley was, truly, the Garden of Earthly Delights for a hacker in those boom years. This time was different. I spoke to several otherwise decent recruiters who all quickly, and to my surprise, made it clear to me that each and every one had been warned away from me by people close to Cygnus.
>Some people will tell you that the Silicon Valley elites back then did not secretly blacklist people from employment. Those people are variously mistaken or lying. Get on the wrong side of a couple of those elites and, in my experience - that was it. You're out. The U-Haul place is down the street. On-ramp to highway 80 is over there. Get out of town. See you in the next life.
>Shortly after that I had to abandon my status as the GNU Guile maintainer (at status conveyed by the FSF, not Cygnus) for financial reasons: I was busy working out some way to keep a roof over my family's head. The project was taken over by one of the "revoc" developers about whose work on it, during that period, I have nothing nice to say.
>Within those next few years the Linux kernel's foothold got quite strong. The FSF greatly diminished its efforts to build a "complete GNU system" and, rather than making sure lots of interactive applications were extensible in the style of Emacs, the GNU project became more of a follower than a leader.
>In those same next few years, a faction of people close to Cygnus who had first hostilely forked GCC then forced its maintainership away from the FSF.
>Overall, the FSF became far less proactive at software development and the original "vision" of a lisp-centric improved version of unix fell by the wayside. One of the last big actions from GNU was to endorse an alternative GUI app framework - GNOME - on the grounds that at least it didn't have the licensing problems that, at the time, KDE had. Any remaining hope of directly developing the lisp-style environment we'd started out to build evaporated right there.
>Here is a different version of some part of the same story (also as told by me, and why should you believe me? :-)
http://basiscraft.com/0800-0100-the-tcl-war.html
>(Where did I go after Cygnus? After several agonizing months I landed a job working remotely for an R&D group at UUNET. That was a gig that went very well for a couple of years. You know, until it was suddenly revealed that the firm was bankrupt and that it's CEO was being arrested. I tell ya', I can't catch a break. ;-)
https://news.ycombinator.com/item?id=12027092
>DonHopkins on July 3, 2016 | parent | context | favorite | on: The Tcl War (1994)
>Around the time leading up to the TCL war, Lua was peacefully and quietly born in a manger at the Pontifical Catholic University of Rio de Janeiro, Brazil: "In 1993, the only real contender was Tcl, which had been explicitly designed to be embedded into applications. However, Tcl had unfamiliar syntax, did not offer good support for data description, and ran only on Unix platforms. We did not consider LISP or Scheme because of their unfriendly syntax. Python was still in its infancy. In the free, do-it-yourself atmosphere that then reigned in Tecgraf, it was quite natural that we should try to develop our own scripting language ... Because many potential users of the language were not professional programmers, the language should avoid cryptic syntax and semantics. The implementation of the new language should be highly portable, because Tecgraf's clients had a very diverse collection of computer platforms. Finally, since we expected that other Tecgraf products would also need to embed a scripting language, the new language should follow the example of SOL and be provided as a library with a C API."
http://www.lua.org/doc/hopl.pdf
https://news.ycombinator.com/item?id=17061858
>And with that diplomatically worded message, RMS kicked of The Infamous TCL War.
>That was Stallman's response to Sun bombastically pushing TCL as the official scripting language of the web, BEFORE Live Oak / Java was a widely known (or evangelized) thing.
>At the point anybody started talking about a Java/TCL bridge, it was already all over for TCL becoming the "ubiquitous scripting language of the Internet".
>Sun's unilateral anointment of TCL as the official Internet scripting language trigged RMS's "Why you should not use Tcl" message, which triggered the TCL War, which triggered Sun to switch to Java.
>After the TCL war finally subsided, Sun quietly pushed TCL aside and loudly evangelize Java instead. The TCL community was quite flustered and disappointed after first winning the title "ubiquitous scripting language of the Internet" and then having the title yanked away and given to Java.
>Any talk of bridges were just table scraps for TCL, the redheaded bastard stepchild sitting outside on the back porch in the rain, smoking a cigarette and commiserating with NeWS and Self.
>Tom Lord's description of what happened is insightful and accurate:
https://web.archive.org/web/20110102015130/http://basiscraft...
>The Infamous Tcl War
>[...] Mr. Ousterhout had, a few years prior, developed Tcl while on the faculty of UC Berkeley - mainly, I think, to have a handy tool for other research and only secondarily as an experiment in language design. And he topped it off with Tk. Tcl/Tk took off in a huge way. It was easy to understand. The source code, written in Mr. Ousterhout's methodical and lucid style, was a joy to read. At the time, about the most convenient option for developing a GUI to run on a unix system was to write C code against the Motif toolkit - an ugly, expensive, and frequently disappointing process. With Tcl/Tk in hand, people started handing out new "mini-GUIs" for this and that, like candy. Tcl/Tk started to find application in some rather intense areas, like, for example, the "control station" software for some oil rigs. It was a smash hit.
>Meanwhile, I don't think I'm letting too many cats out of the bag here, the informal Silicon Valley social network of well placed hackers were quietly and unofficially circulating some very interesting confidential whitepapers from Sun Microsystems. One of their researchers, a fellow called Mr. Gosling, had dusted off a language he'd once led the design of called "Oak". Oak was originally intended for use in embedded systems. Its basic premise was that devices ought to be Turing complete and hackable, whenever possible. Oak's approach to statically verifiable byte-code comes from that origin. Mr. Gosling came out of Carnegie Mellon University and the attiude behind Oak was popular there. As one grad student had quipped a few years earlier: "If a light switch isn't Turing Complete I don't even want to touch it."
>In light of the rising star of web browsers, the folks at Sun conceived the notion of offering up a derivative of Oak to serve as the extension language for browsers. (It is probably worth mentioning here that Mr. Gosling was earlier well known for making one of the very first unix versions of Emacs.) Oak was re-named "Java" and the rest of its history is fairly well known.
>I've read, since then, that up to around that point Brendan Eich had been working on a Scheme-based extension language for Netscape Navigator. Such was the power of the hegemony of the high level folks at Sun that the word came down on Mr. Eich: "Get it done. And make it look like Java." Staying true to his sense of Self, he quickly knocked out the first implementation of Mocha, later renamed Javascript. This phenomenon of Sun's hegemony influencing other firms turns out to be a small pattern, as you'll see.
>Mr. Ousterhout was hired by Sun (later he would spin off a Tcl-centric start-up). The R&D; team there developed a vision:
>Java would be the heavy-lifting extension language for browsers. The earliest notions of the "browser as platform" and "browser as Microsoft-killer" date back to this time. Tcl, Sun announced, was to become the "ubiquitous scripting language of the Internet". Yes, they really pimped that vision for a while. And it was "the buzz" in the Valley. It was that pronouncement from the then-intimidating Sun that led to the Tcl wars.
>Mr. Eich, bless his soul, brute-forced passed them, abandoning Scheme and inventing Javascript. [...]
https://news.ycombinator.com/item?id=29379272
>DonHopkins on Nov 29, 2021 | parent | context | favorite | on: CPython's main branch running in the browser with ...
>For Netscape in 1995, I believe Python would have been a better choice than JavaScript, but Lua would have been an even better choice, given how much smaller, simpler, and more efficient Lua is, and the eventual excellence of LuaJIT. (If only Lua indexed its array from 0 instead of 1...)
>But Python and Lua didn't "look like Java" enough for Netscape. [...]
https://news.ycombinator.com/item?id=30405409
>DonHopkins on Feb 20, 2022 | parent | context | favorite | on: Fengari – Lua for the Browser
>I wish Netscape had chosen Lua instead of bothering to invent JavaScript. Python would have also been much better than JavaScript, but Lua would have been perfect. But at least they didn't choose TCL, as Sun was pushing before they switched gears to Java after the Great TCL War. And personally, I would have preferred PostScript (which was the basis of NeWS, with a Smalltalk-like OOP system) or ScriptX (which was like Scheme or Dylan with "normal" infix syntax and a CLOS-like OOP system) to JavaScript.
>If all the time and effort and treasure that was wasted cobbling together JavaScript from scratch with all its naive unforced design flaws and security holes and interoperability issues -- and then everyone else pissing away so much effort working around and fixing subtle bugs in JavaScript code due to those terrible design flaws (cough cough "this" cough cough "equality") -- had been put into Lua instead, which was cleanly designed from the start by incredibly smart people who actually had a clue about what they were doing, the world would be a much better place.
>People who are that confused about equality shouldn't design programming languages:
https://dorey.github.io/JavaScript-Equality-Table/
>"All animals are equal, but some animals are more equal than others." -George Orwell, Animal Farm
[...]
https://news.ycombinator.com/item?id=31117713
>DonHopkins on April 22, 2022 | parent | context | favorite | on: The Birth of Tcl
>The Tcl War (1994) (vanderburg.org)
https://news.ycombinator.com/item?id=12025218
https://vanderburg.org/old_pages/Tcl/war/
>Why you should not use Tcl
https://wiki.tcl.tk/16730
[...]
They are all programs.
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.
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.
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".
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".
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.
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.
If I think I will never use it again, never return to it, and no one else will ever use it, it’s a script: a thing that helped me automate just this one thing, or do it more efficiently/quickly.
If I will ever return to it, or if someone else will use it, it’s a program.
I wrote a lot of scripts when I was younger. I regret that.
Because of the time I have to spend now, figuring out WTF I meant and why I did it that way.
Now I write more (but not all) programs. Costs me more up front, saves me so much tomorrow, next week, etc.
(One of the simplest differences is good comments, written on the assumption I won’t in fact remember the motivation for whatever this is/was. That and error checking and sound defensiveness.)
If I will ever return to it, or if someone else will use it, it’s a program.
I wrote a lot of scripts when I was younger. I regret that.
Because of the time I have to spend now, figuring out WTF I meant and why I did it that way.
Now I write more (but not all) programs. Costs me more up front, saves me so much tomorrow, next week, etc.
(One of the simplest differences is good comments, written on the assumption I won’t in fact remember the motivation for whatever this is/was. That and error checking and sound defensiveness.)
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.
A program is a script with an army and a navy.
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.
That's my definition anyway.
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.
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.
Scripts are conveniences; hacks.
Scripts are conveniences; hacks.
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.
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.
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.
Too many lines can be drawn, I think.
- 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 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
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
“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
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.
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 have never seen the emperor’s distinction between scripts and programs. There is no practical difference between them in the world of computing.
#!/bin/interpreter -this-is-a-script
'app'
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?