Is there a useful distinction between "programming" and "scripting" languages?
Erann Gat
The argument about whether HTML is or isn't a "programming" language
reminded me of something I've been wondering about for a while: is there a
useful distinction to be made between "programming" and "scripting"
languages? My personal opinon is that there is not, but I'd like to know
what others think.
Thanks,
Erann
Eduardo Muñoz
I don't go as "low" as Duane (setting preferences
is programing), but I consider the definition or
description of a _process_ to be programming. I
think that a recorded macro (with Emacs or MSWord)
is a form of programming and so is a manufacturing
plan.
From this POV scripting is a subset of
programming.
--
Eduardo Muñoz
Wade Humeniuk
language when one is scripting (control constructs, etc). So my ideal scripting
language is also a programming language.
There are distinctions made, as the syntax of a scripting language is usually
quite different from the programming language it is implemented in. Scripting
languages have application specific functionality. Scripting languages are
then, I suppose, 4GLs (scratching my head). For me calling a csh script a
scripting language is wrong, but spacecraft "command sequencing languages" are.
So maybe I would modify my first paragraph to say that I would like the syntax
of a scripting language to be the same as the language it is programmed in.
Thus a good scripting language would be a superset of the programming language
(just like Lisp can be).
Wade
"Erann Gat" <g...@jpl.nasa.gov> wrote in message
news:gat-160902...@k-137-79-50-101.jpl.nasa.gov...
Pascal Costanza
My impression is that most scripting languages start out as trying to be
as simple as possible for a certain task. However, in the long run, most
of them tend to grow into "full-fledged" general-purpose languages. I
don't think that scripting languages make any real sense and in many
cases it would have been better if their designers had started with "the
real thing" from the very beginning.
I think that scripting languages are mainly a social phenomenon and that
they don't exist for their technical merits. Most "production languages"
are intentionally very restricted, and the term "scripting language"
gives developers a good excuse to use something more flexible. "Yes, we
follow the company guidelines and use C++; we only use this little
scripting language, but only for glueing our components." This is just
another variation of Greenspun's tenth rule.
This doesn't apply only to scripting languages. For example, AspectJ can
also be regarded as a tool that tries to give developers some of the
power of CLOS that the Java designers' have deliberately taken away from
them. They even praise the fact that AspectJ can generate pure Java
sources, to make it easier for managers to accept it.
We're living in a post-modern world...
Pascal
Christopher Browne
At one point, "scripting" generally implied that programs were stored
as text, but since Python code tends to get automagically transformed
from .py to .pyc (bytecode), and Perl is looking to bytecode compile
to "Parrot", that's decreasingly true.
Originally, it also referred to the notion that you'd have "monoliths"
of (generally) C/C++ executables that you'd use the "scripts" to glue
together to do something useful.
When they got stuff similar to Perl DBI added, providing direct access
to databases, as well as full-scale "object class" systems and
reasonably complete data structure "trees," you could start composing
complete applications in the "scripting" languages, which represents
quite a different approach than the "use a Bourne shell script to run
the C programs" thing of the days of yore.
I'd agree with the idea that the distinction has faded to
near-irrelevance.
--
(concatenate 'string "chris" "@cbbrowne.com")
http://cbbrowne.com/info/sap.html
"There is no psychiatrist in the world like a puppy licking your
face." -- Ben Williams
Tim Bradshaw
I think that there isn't, and that the distinction is actually
harmful.
Cley gets quiet a lot of its income from teaching courses on
Unix-related topics, mostly system admin. Unix System administrators
spend a lot of time writing and using `scripts' in the many Unix
scripting languages. One thing that is quite important, I think, is
to think of these scripts the same way you would think about programs
- in particular to worry about things like testing, error protection,
performance (not usually an issue, but it can be - I've seen a script
which ended up calling `du' hundreds and hundreds of times, and which
badly needed to be rewritten to call it once and then make use of the
resulting output many times), user interaction, and so on. All of
these considerations make the process of writing good system scripts
really just the same as programming. The languages may be interpreted
line-by-line (or they may not), but really this doesn't matter (apart
from the endless nightmare of typical Unix shells repeatedly reparsing
stuff...).
One reason, perhaps, to make the distinction is that it may be less
frightening to people who do not think of themselves as programmers to
talk about `scripting' rather than `programming'.
--tim
Daniel Barlow
The phrase "scripting language" seems generally to be used to describe
a language which is both (a) great for quick hacks and (b)
vomit-inducingly ugly for anything more than 200 lines long or where
performance is an issue
As an advocate for languages which are (a) _without_ being (b) - and,
ObCL, a user of a language which is _already_ (a) but not (b) in many
problem domains, I don't find it "useful" to use terms which conflate
the two.
Other people may have different uses in mind, I suppose.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Barry Margolin
I think the original intent of "scripting" was that it was basically the
same language that you used as the interactive command language. So on a
Unix system, this is the shell, while on a Lisp Machine it would be Lisp.
On Unix, as scripts got more complex, tools like AWK sprang up. Since this
is a language that's mostly used to augment the capabilities of scripts, it
was also considered a scripting languge. Then Perl expanded on the
capabilities of AWK, so it was considered a scripting language by
association.
Even when languages, such as AWK and Perl, are not actually the interactive
CLI, it's also useful to consider them scripting languages if they're
designed to fit natually into the CLI model. AWK is often used to process
the output of commands that are piped to it, and Perl makes it very easy to
invoke other commands and pipe data to/from them.
IMHO, Perl is on the fence. It's useful for post-processing command
output, but I've written a number of complex Perl scripts that never
interact with other commands; we use it as a "high-level C".
--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Christopher Browne
> In article <gat-160902...@k-137-79-50-101.jpl.nasa.gov>,
> Erann Gat <g...@jpl.nasa.gov> wrote:
>>The argument about whether HTML is or isn't a "programming" language
>>reminded me of something I've been wondering about for a while: is there a
>>useful distinction to be made between "programming" and "scripting"
>>languages? My personal opinon is that there is not, but I'd like to know
>>what others think.
>
> I think the original intent of "scripting" was that it was basically the
> same language that you used as the interactive command language. So on a
> Unix system, this is the shell, while on a Lisp Machine it would be Lisp.
You're missing the /classic/ place where scripting is still done,
heavily.
MVS.
On MVS, you write applications in "programming languages" like COBOL
or PL/1 or such, and then write a JCL script that attaches their file
descriptors to actual files, and controls the sequencing of running
various "programs."
Love it or hate it, that's certainly a /big/ part of where the notion
of "scripting" came from, and people are still writing JCL...
--
(reverse (concatenate 'string "ac.notelrac.teneerf@" "454aa"))
http://cbbrowne.com/info/spiritual.html
"How can you dream the impossible dream when you can't get any sleep?"
-- Sam Robb
Erik Naggum
| The argument about whether HTML is or isn't a "programming" language
| reminded me of something I've been wondering about for a while: is there a
| useful distinction to be made between "programming" and "scripting"
| languages?
A scripting language modifies a working system to do certain additional tasks
or existing tasks differently and cannot exist without the working system. A
programming language builds a working system from scratch.
Take Perl. It started out as an ugly scripting language that took a working
Unix system and made certain labor-intensive tasks, provided you had done
something stupid to begin with, less labor-intensive, so you suddenly had
reason not to do them less stupidly. It added nothing useful to the Unix
environment except a little more convenience than the standard tools if you
had been a bonehead. In effect, Perl encouraged stupidity from Day 1 and
made it virtually impossible to redesign things more intelligently because so
many people had Perl scripts that depended on the old boneheaded design and
execution. Also, being a great fan of regular expressions, Perl discouraged
people from developing languages and syntaxes that were actually parsable by
non-idiot software. Being such a horrid approximation to programming, Perl
fit scripts with the operating principle "Damn the false positives and false
negatives alike, full stream ahead!" In effect, Perl required both a working
system to be a parasite off of, and users who were willing to tinker with the
scripts if they produced erroneous results. In all likelihood, there was no
change at all to the labor-intensiveness, but the labor was more "fun" for a
certain class of people. Now, industrious retards can be a horrible thing.
Over a number of years, close to a decade, Perl accreted bits and pieces from
programming languages and became usable in lieu of a programming language by
people who lacked the mental wherewithall to do programming. Tinkerers,
repairers, handymen, the auto mechanics of the IT industry, all flocked to
Perl because they could tinker so well with it with no required knowledge or
skills. Thus was "programmering performed by tinkerers" born as a concept,
and the tinker toys of the unskilled became better and better. Necessarily,
a number of good people who watched this gruesome development unfold found
that they could not let it do so without at least some guidance from working
brains, and Perl acquired more and more features of a programming language.
Yet, it still remains nothing mor than a scripting language, because it does
not only require the entire Perl system to be present to amend its behavior
according to the scripts, it does not even have the /potential/ to be
stand-alone.
So a different way to explain the difference is that scripting languages are
parasitic where the programming languages are the hosts.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Christopher Browne
> So a different way to explain the difference is that scripting languages are
> parasitic where the programming languages are the hosts.
I quite disagree, and would point to JCL on mainframe platforms as the
characteristic example of symbiosis.
- "programming languages" are used to write the 'guts' of the
functionality that is required, but in a manner that is unaware of
the specific computer resources that will be used with the program
- The scripting language then 'glues' the program together to things
like files.
Perl in particular grew from being a somewhat more convenient "glue"
into having enough functionality to allow using it as the 'programming
language,' so that it was no longer 'controlling' real work being done
by other programs, but rather doing the work itself.
The 'Scripting Way' involves an approach rather like that of MVS/JCL,
where you /intentionally/ write programs to be somewhat 'abstract,' so
that they realistically can't function on their own, but /need/ to
have a 'scripting' stage where someone decides how they are to be run.
Modern use of Perl/Python/PHP/Ruby/... is often not done with a
"Scripting" mindset.
--
(concatenate 'string "cbbrowne" "@cbbrowne.com")
http://cbbrowne.com/info/scripting.html
Q: What does FAQ stand for?
A: We are Frequently Asked this Question, and thus far have no idea.
Kaz Kylheku
There is no useful distinction between scripting and programming. The
word ``script'' simply refers to a fuzzy subset of programs which are
stupid hacks that work for the original programmer. As soon as these
hacks acquire customers, they become programs.
You can use the POSIX shell language to write quick hacks for
yourself; but serious shell programs require attention to detail, so
that they will always work right. Is it still scripting if you have
concerns about exceptional cases, portability, maintainability,
generality and so forth?
Another fuzzy definition for ``script'' is that it's a relatively
simple list of instructions which coordinate the execution of some
other software, which is itself tailored to some task. Most of the
complexity is in that software rather than the script. So you might
have some script run by an image processing software to apply a set of
transformations, for instance. The scripting language may be nearly
useless for doing anything but expressing such operations within the
context of that application. Scripting languages are usually
represented in text only: scripts are rarely retained in compiled
form, and require the host application. There is often poor support
for modularity or even decomposition into multiple files.
Is this a definition that leads to a useful distinction? That is hard
to say. For me, the term ``script'' vaguely triggers the above
semantics, which tell me roughly what type of software I'm dealing
with and what is its likely relationship to its immediate environment
and the rest of the world.
Joe Marshall
designer punted on anything that required more than a half-moment's
thought.
Barry Margolin
A scripting language is a programming language for users who don't know
(or don't want to know) they're programming.
Bulent Murtezaoglu
[...]
TimB> One reason, perhaps, to make the distinction is that it may
TimB> be less frightening to people who do not think of themselves
TimB> as programmers to talk about `scripting' rather than
TimB> `programming'.
This attitude is getting rarer along with people being rather apologetic
about quick/dirty/non-robust programs. Now it seems that people _like_ to
think they are programming even when they are producing HTML.
The crowd you train at Cley might have the vague intuition that scripts are
things that take care of one kind of tedium -- typing successive commands
with some switches in the shell.
cheers,
BM
Len Charest
> The argument about whether HTML is or isn't a "programming" language
> reminded me of something I've been wondering about for a while: is there a
> useful distinction to be made between "programming" and "scripting"
> languages?
No.
"Scripting" is a subset of "programming".
Erik Naggum
| The argument about whether HTML is or isn't a "programming" language
| reminded me of something I've been wondering about for a while: is there a
| useful distinction to be made between "programming" and "scripting"
| languages?
* Len Charest
| No.
|
| "Scripting" is a subset of "programming".
I am quite surprised to see several of these responses. If things that are
A are a subset of things that are B, but there is no distinction between A
and B, then the two sets should also be identical. Although a subset of a
set may be identical to the set in strict mathematical formalism, I find it
quite odd to use these terms this way when the purpose is to say that the
two sets are identical, so that leaves me with the only option that one of
the two statements are false. I err on the side of a distinction because it
is quite possible that one would not be able to name the distinction, but
still know of at least one programming language that is not a scripting
language. I believe the obvious distinction is found in the fact that not
all programming languages are scripting languages. I actually wonder why
people seem to want to deny this.
Frank A. Adrian
> On MVS, you write applications in "programming languages" like COBOL
> or PL/1 or such, and then write a JCL script that attaches their file
> descriptors to actual files, and controls the sequencing of running
> various "programs."
And on an AS/400, there are only commands. The only way to get any control
structures around these commands is to compile a CL (Command Language)
program that includes them and run the resulting program! All-in-all,
there are many ways to interact with a machine and the lines between
shells, programming languages, and scripting systems is pretty silly. This
is something that is pointed out by the likes of B5500's, Lisp Machines,
and others of their ilk, but never seems to be adopted by the mainstream.
So it goes...
faa
Kaz Kylheku
> non-idiot software. Being such a horrid approximation to programming, Perl
> fit scripts with the operating principle "Damn the false positives and false
> negatives alike, full stream ahead!"
I once joined the comp.unix.shell newsgroup and after a while started
criticizing non-robust scripting examples within articles---and the FAQ itself!
By that I mean severe mistakes, like using poorly quoted parameter expansions
that would lead to whitespace sensitivities. Garbage like
for x in *; do blah $x ; done
will fail miserably if * expands to files with spaces in their names,
and will not glob names that begin with a dot.
Or, expanding the parameters to a script or function using anything other
than "$@" will cause trouble with parameters that contain spaces.
My well-intended advice wasn't well received at all. I received stupid flames
informing me, for instance, that users who put spaces in things deserve what
they get, and so it's not worth uglifying scripts for the sake of a few idiots.
That's basically the culture from which Perl emerged, and all the stupid crap
that came before it, like the ``find | xargs'' dynamic duo.
Tim Bradshaw
> I am quite surprised to see several of these responses. If things that are
> A are a subset of things that are B, but there is no distinction between A
> and B, then the two sets should also be identical.
My claim, more or less, is that the two activities should really be
identical: people who script should be programming, because all the
considerations are the same to me. Some `script' which manages, say,
some stage in the boot process of a Unix machine really needs to be
robustly written, and a `script' which runs off the back of a web
server possibly even more so - it is typically sitting right in the
sights of potential attackers and it needs thick armour plate and big
guns.
However, I may have missed the point: I'm describing activities, not
languages. It probably is the case that there are `scripting
languages' and `programming languages' and they are two different
animals. I just think the considerations when using them should be
pretty much the same, and this is more important for me.
--tim
Software Scavenger
> language. I believe the obvious distinction is found in the fact that not
> all programming languages are scripting languages. I actually wonder why
The way I understand the words, a program is to program a machine, and
a script is to program a program. A Posix shell script, for example,
programs a Posix shell. HTML does not seem to me like a programming
language or a scripting language, but just a markup language.
As the distinction between programming the machine and programming a
program blurs, the distinction between programs and scripts blurs with
it. The words gradually evolve closer in meaning but also gradually
develop incidental submeanings in different contexts, making their
distinction lose its usefulness for some things while gaining
usefulness for others.
This is of course just my opinion, and only from idle pondering about
it, not from any formal knowledge of such things. But it seems on the
surface to be a good way to think of the distinction between the
words.
Barry Margolin
> I am quite surprised to see several of these responses. If things that are
> A are a subset of things that are B, but there is no distinction between A
> and B, then the two sets should also be identical.
But they aren't identical. If you write a program in C or Lisp, you're not
considered to be scripting (even when writing a program in Lisp on a Lisp
Machine). Scripting is a kind of programming.
Here's a possible analogy: I can make simple dinners for myself by boiling
pasta or microwaving pre-packaged foods. So I'm able to do simple cooking,
but I wouldn't consider myself a chef. Scripting is like heating up a TV
dinner, programming is like making a gourmet meal.
ozan s yigit
> That's basically the culture from which Perl emerged...
assessing a culture by a mailing list and a few flames is surely not
very helpful. just imagine where one may end up from lang.lisp
for example...
oz
--
you take a banana, you get a lunar landscape. -- j. van wijk
Joe Schaefer
[...]
> My well-intended advice wasn't well received at all. I received stupid
> flames informing me, for instance, that users who put spaces in things
> deserve what they get, and so it's not worth uglifying scripts for the
> sake of a few idiots.
>
> That's basically the culture from which Perl emerged, and all the
> stupid crap that came before it, like the ``find | xargs'' dynamic duo.
There's certainly a bunch of evil shell-inherited cruft in Perl,
but it's usually avoidable in practice. I've never read
comp.unix.shell, but if you've tried reading clp.misc for more than
a few weeks, I think you'd have a very hard time painting it with
that same brush.
--
Joe Schaefer
Hannah Schroeter
Kaz Kylheku <k...@ashi.footprints.net> wrote:
>[...]
>Or, expanding the parameters to a script or function using anything other
>than "$@" will cause trouble with parameters that contain spaces.
Rather ${1+"$@"} if you want to be compatible to more Bourne like
shells. "$@" does substitute one empty word on some shells when
you have no arguments at all.
>[...]
Kind regards,
Hannah.
Duane Rettig
Hmm. Here we are, general purpose programmers, talking about general
purpose language types/styles, trying to distinguish them. I had trouble
pinpointing the difference myself, until I went back to my days as a
test engineer. There, we had domain-specific "compiled" languages that
ran the tester, and scripting languages that aided us (and the techs on
the manufacturing floor) to build, modify, or glue together tests on
the fly. In the age of compile/link/load/go, this was the interactive
solution. It was limited in scope, a trait actually designed into the
language, mostly based on the need to prevent its user from being able to
do _too_ much on the machine. I've seen similar applications of scripting
languages in other domain-specific applications, with similar purposes and
results. RMS once made a bold and innovative statement that such languages
should in fact be _real_ languages (sorry, I don't have a reference, though
he did repeat it in the talk he gave at the 1998 LUGM conference).
My theory is that scripting languages were borne out of the "computer
phobia" phenomenon. They were built for people who were "afraid to
touch" the computer, other than to run the application (some people
wouldn't even do that; they would use a mechanical word-processor, for
example, with all of its breakdowns, rather than use one on a computer,
simply because "it is a _computer_". The scripting languages tended to be
"dumbed down" to meet (not these people's expectations, but) these people's
fears. Well, that computer phobia phenomenon has died down quite a bit,
but the scripting languages live on, mainly due to their usefulness as
an end-around to the compile/link/load/go process. It's interesting to
watch a dumbed-down scripting language grow ad hoc to meet the challenge
of a group of people whose fear shrinks, and who want ever more features.
As the power of scripting languages approaches that of general purpose
languages, it does so from the direction of ad hoc design, and thus tends
to turn the stomachs of those who have always used gp languages for gp
problems.
--
Duane Rettig du...@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Erik Naggum
| assessing a culture by a mailing list and a few flames is surely not very
| helpful. just imagine where one may end up from lang.lisp for example...
The fact that people here get flamed for being idiots and people in the Perl
culture are flamed for being smart should be a pretty good indicator.
Len Charest
> * Erann Gat
> | is there a
> | useful distinction to be made between "programming" and "scripting"
> | languages?
>
> * Len Charest
> | No.
> |
> | "Scripting" is a subset of "programming".
>
> all programming languages are scripting languages.
Then we are in violent agreement.
Paul Wallich
Duane Rettig <du...@franz.com> wrote:
>Tim Bradshaw <t...@cley.com> writes:
Scripting languages weren't invented to deal with computer phobia, but
rather with information overload. Your first paragraph, talking about
scripting languages to program tests and test suites on the fly hits the
nail on the head, imo. You don't want the users of a scripting language
to be confronted head-on with the full complexity of a conventional
programming language because they have tasks to accomplish -- which only
in a subsidiary fashion require programming. Good scripting languages
provide high-level, succinct tools for doing the things that a user
needs to do, and put some kind of obstacle (even if only obscurity) in
the way of doing things completely unconnected to the task at hand.
Ideally there should be lots of them, each with a fairly uniform look
and syntax.
Eventually, of course, users will want to do things that the originator
of the scripting language never thought of, or the task (and the machine
feature set) at hand will change, and then you need a general-purpose
programming language, and a seamless way of moving between the
task-specific and fully-expressive modes. If this looks like Greenspun's
Law yet again, that's because it is, but there's an important twist.
Those limited, task-specific sublanguages are crucial to actually
getting the job done -- you don't want' people starting from scratch all
the time just because it's more elegant. So every CL program that solves
a real-world problem ends up containing a buggy, incomplete version of
some domain-specific scripting language...
paul
ozan s yigit
> My theory is that scripting languages were borne out of the "computer
> phobia" phenomenon. They were built for people who were "afraid to
> touch" the computer, other than to run the application (some people
> wouldn't even do that; they would use a mechanical word-processor, for
> example, with all of its breakdowns, rather than use one on a computer,
> simply because "it is a _computer_". The scripting languages tended to be
> "dumbed down" to meet (not these people's expectations, but) these people's
> fears. [...]
one person who has written and spoken at some length about the differences
between scripting languages and other languages is john ousterhout. i remember
walking out of one of his talks with frustration, but perhaps others will find
more value in what he has to say: see eg.
http://citeseer.nj.nec.com/ousterhout97scripting.html
[two "scripting languages" that should be reviewed for their place
in history: hypercard and newtonscript...]
oz
--
practically no other tree in the forest looked so tree-like as this tree.
-- terry pratchett
Michael Sullivan
> The argument about whether HTML is or isn't a "programming" language
> reminded me of something I've been wondering about for a while: is there a
> useful distinction to be made between "programming" and "scripting"
> languages? My personal opinon is that there is not, but I'd like to know
> what others think.
I think there's a distinction, but (a) it's not hard and fast, and (b)
scripting is a subset of programming -- they are not completely
different things.
Scripting is a kind of high-level programming where you depend on
applications already written to perform complex functions, and the
script drives those applications, or glues them together. In modern
terms, you could easily argue that nearly all programming is essentially
this. We depend (and *should* depend) on libraries and OS calls to do
nearly everything that is not specifically new function. So even at
level that you'd *never* call "scripting", you're doing a lot of exactly
what "scripting" is.
On the other side, "scripting" languages these days are, more often than
not, general purpose, even if they don't make as good general purpose
languages as others. Because there are always things that a scripter
thinks of to do that the original author of the scriptable software
didn't, and having a Turing-complete semi-general purpose scripting
language makes just about every add on possible without having to
redevelop large pieces of the software in question.
I use applescript a lot, and it's a classic example of a modern
scripting language. But it is turing complete, and I've certainly
written hacks in it that don't depend on any other software (other than
the applescript interpreter). Is it a scripting language or a
programming language? Well, I'd call it a scripting language because
its *strength* is driving other apps. It is a programming language, and
I've used worse, but it's significantly less powerful than Lisp, and
lacks some essential features that would be required to compete with
java/C/etc. as a general purpose language (e.g. I can create a hash
table object, but it doesn't actually do O(1) lookups and k is large,
and I have to work around arbitrary interpreter limitations before
there's all that much data in it.).
OTOH, I script apps in AS a lot, so I'm very familiar with it and have
an IDE open all the time. Thus I find myself writing small general
purpose programs in it fairly often. For anything that that doesn't
depend on driving other software, and which requires a large data
structure, or would take more than a day or so to program, I use a
different language.
Anyway, I think it's a somewhat useful distinction, but it's loose and
becoming looser. I also consider it a "kind of" relationship.
Scripting is a kind of programming, and a scripting language is a kind
of programming language.
Michael
--
Michael Sullivan
Business Card Express of CT Thermographers to the Trade
Cheshire, CT mic...@bcect.com
Åsmund Ødegård
> reminded me of something I've been wondering about for a while: is there a
> useful distinction to be made between "programming" and "scripting"
> languages? My personal opinon is that there is not, but I'd like to know
> what others think.
I have never seen the words definied, but at least in the sci.comp
community, a program do some real work, while a script glue stuff
together. So it is more a matter of function than language - you may
even have C++ scripts or lisp scripts, that depend on the kind of work
the thing do. Some languages, like e.g. Python are more geared towards the
"glue" function in that it have interfaces to a wast amount of other
libraries and languages, and hence tend to be used as solely as a
scripting language, and are consequently called scripting languages. The
same holds true for,say, Fortran and C, only in the opposite corner -
those are therefor called programming languages. Stuff in between like,
e.g., lisp can be called whatever you like...
btw, since a operating system tend to be a glue between the user and
some hardware which do most of the critical work, maybe a operating
system is simply a collection of scripts in some sense?
mvh,
--
[simula.research laboratory]
Åsmund Ødegård
Scientific Programmer
phone: 67828291 / 90069915
http://www.simula.no/
-- auto sig --
MAR 14:16 And his disciples went forth, and came into the city, and found as
he had said unto them: and they made ready the passover.
Daniel Barlow
> results. RMS once made a bold and innovative statement that such languages
> should in fact be _real_ languages (sorry, I don't have a reference, though
> he did repeat it in the talk he gave at the 1998 LUGM conference).
Might have been "Why you should not use Tcl"
| The principal lesson of Emacs is that a language for extensions should
| not be a mere "extension language". It should be a real programming
| language, designed for writing and maintaining substantial programs.
| Because people will want to do that!
http://www.vanderburg.org/Tcl/war/0000.html
Duane Rettig continues:
> As the power of scripting languages approaches that of general purpose
> languages, it does so from the direction of ad hoc design, and thus tends
> to turn the stomachs of those who have always used gp languages for gp
> problems.
Aaron Crane, from "Experiences of Using PHP in Large Websites"
| In cases where PHP has been determined to be inappropriate, what
| language should be used? There is considerable choice here; few
| languages are as bad as PHP for doing serious development work.
http://www.ukuug.org/events/linux2002/papers/html/php/index.html
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Erann Gat
> * Erann Gat
> | The argument about whether HTML is or isn't a "programming" language
> | reminded me of something I've been wondering about for a while: is there a
> | useful distinction to be made between "programming" and "scripting"
> | languages?
>
> A scripting language modifies a working system to do certain
> additional tasks or existing tasks differently and cannot exist
> without the working system. A programming language builds a
> working system from scratch.
Hm. That makes a language's status dependent on the context in which it
is used. Lisp running on Unix would be a scripting language on that
definition (but not Lisp running on a Lisp machine).
E.
Erik Naggum
| The argument about whether HTML is or isn't a "programming" language
| reminded me of something I've been wondering about for a while: is there a
| useful distinction to be made between "programming" and "scripting"
| languages? My personal opinon is that there is not, but I'd like to know
| what others think.
* Michael Sullivan
| I think there's a distinction, but (a) it's not hard and fast, and (b)
| scripting is a subset of programming -- they are not completely different
| things.
This thread puzzles me greatly, so I have to ask a pretty stupid question
because I realize that I may have an invalid assumption as to what people
mean by something I have taken for granted for years.
If I say that there is a distinction between A and B, I intend to communicate
that the set of A things and the set of B things are not identical, as they
would be if there were no distinction between A and B, but this does not
preclude one from being a subset of the other. Quite the contrary. A subset
relation is distinctive. I read several responses to this question to mean
that others would say that there is a distinction between A and B only if no
A is a B and no B is an A and that a subset relation is /not/ a distinction.
I take the many responses that people have posted about this to mean that a
distinction exists between A and B if they are at the same hierarchical level
in some model or other and that subset relations are a different kind of
animal altogether. Since I have no other word for this subset relation than
distinction, I wonder how this works.
For instance, one might say that there is a distinction between a computer
and a personal computer in that a computer is not restricted to one-person
use, but a personal computer is. Some people here would, I presume, answer
"no, there is no distinction, personal computers are a subset of computers",
which does not communicate "there is no distinction" = "they are the same",
but "there is no distinction" = "subsets are a different kind of not-sameness
than distinctions". In this model of usage, there would be a distinction
between a server and a personal computer, because both are refinements of the
concept "computer" at some notion of the "same level", but there would not be
a /distinction/ between a computer as the superclass and the server as the
subclass.
Since we have discussed hierarchical classifications and ontologies lately,
as well, I wonder if there is not something deeper going on in here that has
some influence on how people approach classification. It may be useful to
know that I had first approached classification in libraries before I found
books about computers in the libary whose math section I had devoured, and
that I was taught the basic ten classes in Dewey before I was ten myself.
The reason I brought up Dewey's just recently was that the 5th Norwegian
edition had been completed and announced with some fanfare in circles I had
not worked with for several years; yet it occurs me that much of my thinking
about concepts and ontologies has indeed been shaped by Dewey's in ways I
have not been fully aware. For instance, a simple concept like an automobile
could have one classification and the particular kind of automobile known as
sports utility vehicles another, subordinate to automobiles, but people who
object to distinction would presumably never classify anything as automobiles
but would have to classify non-SUVs in a new, separate class and would be
unhappy to find that there was a category for SUVs but that both other kinds
of automobiles and automobiles in general had a class that appeared both to
subsume SUVs and not. The same problem comes up with comp.lang.lisp and
Common Lisp and Scheme. Some people have strongly objected to requests not
to discuss Scheme matters in the "general Lisp newsgroup" even though Scheme
has its own specialized newsgroup, because, presumably, it should be allowed
since the general category subsumes the more specific. It occurs to me that
the objections have been over fundamental differences in concept-formation
and hierarchical organization of knowledge rather than over "is Scheme a
Lisp?".
As I started to wonder about this, I also realized that some of my failure to
understand objections to classifications that have appeared absolutely
natural to me may not be obvious without a similar background, and that the
reason for what I see as ignorance and wheel-reinvention in the Semantic Web
community may come from different schools of thought. I do not, however,
believe that I have been "brainwashed" by Dewey's classification but rather
that I found it so amazingly natural that I internalized it effortlessly, but
I have also not been obsessing about it and "thinking in Dewey numbers" when
I read books or articles. It has therefore not been conscious when I have
organized my own 1350-volume library roughly along Dewey lines by having
sections of my apartment dedicated to their own areas. This has likewise not
been conscious when I have objected to discussing some topic X in a newsgroup
for super-X when X had its own newsgroup.
From another point of view, that two things have similarities and might be
the same for some purposes, does not mean that they are not distinct for
other purposes, nor vice versa. Therefore, "A and B are distinct" does not
mean that A and B are not the same in /some/ respects, any more than "A and B
are the same" does not mean that they are not distinct in /some/ respects,
for the obvious reason that no two things are identical. Likewise, I would
tend to discuss some specialized class of things in their more general
setting without having a strong urge to point out that the more general
meaning is intended or that I did not mean the specialized class only, but I
do object to statements that attempt to make attributes stick to the broader
class when the observations have only been about a narrower class or about
individuals whose classification is all but certain, mostly because such
statements are noxious pollutants in the information flow; they are the seeds
of many false yet unchecked conclusions. This applies to statements about
Scheme that are imputed to Lisp in general, to statements about the self-
destructive black ghetto culture imputed to blacks in general, to statements
about the most dangerous president of the United States ever imputed to the
American public, to statements about Nigerian §419 advance fee scams and
African businesses in general, and other similar rather obvious instances.
Subsets and supersets appear to pose a philosophical problem of some sort. I
have obviously not solved the problem, since I am only beginning to become
aware of it, but I wonder if most people are equally unaware of how they deal
with classification. The discussion on the use of Dewey in particular showed
that there are implicit assumptions at work at some level and that I have
just been "lucky" to have been exposed to the Dewey model and perhaps other
models that are very similar to it. This model obviously works sufficiently
well that I have not (hitherto) noticed any fault in it. I can only imagine
that most other people have the same observations for their models. Worse, I
have not found any serious discussion of this topic in the philosophy I have
read other than the exposition of systems of concept-formation that I already
accepted. I may even have "chosen" those philosophy texts because they fit
some early, pre-conceptual model that made sense. Others I have talked to
over the years have also reported that they picked their philosophies and
even (non-inherited) religions based on reading lots of material and slowly
focusing on things that made more sense than others. I have long known that
what makes sense to people is a part of their personality but fairly recently
(a couple years) became aware that how a person forms expectations and deals
with frustrations thereof is also a personality trait. I do not exclude the
possibility that concept-formation and classification are also personality
traits or similarly deeply ingrained and unquestioned, as (1) it appears to
be hard to parameterize (no philosophers I know of have described and used
more than one model, but I would appreciate evidence of counter-instances),
(2) many deeply rooted disagreements and misunderstandings appear to be
explainable in terms of differences in classification models or systems, (3)
most discussions about ontology breaks down with people choosing a small set
of diverging ways.
To wrap this up, it appears that a simple question such as asking if there
are distinctions or a distinction between scripting languages and programming
languages implicitly requests the responder to reveal parts of his scheme for
classification or theories of concept-formation, but since this is such a
deepl ingrained issue, disagreements and confusions result when the nature of
distinction and sameness are not made explicit. The question might therefore
more productively be posed to learn how people have classified languages in
either category, and the to see whether any of the four possible categories
(A) non-scripting, non-programming languages, (B) scripting, non-programming
languages, (C) non-scripting programming languages, (D) scripting programming
languages, are empty and under which conditions each language would be put in
each category. For instance, I would put HTML in category A, but I wonder
what those who consider it a programming would do with the scripting aspect.
I apologize for the fuzzyiness of the preceding, I realize that I may be
groping in the dark for the proverbial black cat in the coal cellar that may
or may not be there.
Thien-Thi Nguyen
> [growing understanding of people and self]
i'm glad to see this!
> The question might therefore more productively be posed to learn how
> people have classified languages in either category, and the to see
> whether any of the four possible categories (A) non-scripting,
> non-programming languages, (B) scripting, non-programming languages,
> (C) non-scripting programming languages, (D) scripting programming
> languages, are empty and under which conditions each language would
> be put in each category. For instance, I would put HTML in category
> A, but I wonder what those who consider it a programming would do
> with the scripting aspect.
(i.e., there's four sides to every coin... ;-)
whether or not it is productive is subject to the vagaries in conception
you mention. let's just say it's nice to be entertained by diversity in
expression (for the most part) and that trying to stay patient w/ those
still growing their understanding is a challenge often (but not always!)
well-rewarded.
thi
Erik Naggum
| That makes a language's status dependent on the context in which it is used.
| Lisp running on Unix would be a scripting language on that definition (but
| not Lisp running on a Lisp machine).
This just goes to show how differently we conceptualize. I do not see a
runtime system as an application in itself. If, however, the application
merely runs inside the Lisp system which is also an application from the
operating system's point of view, the question becomes whether the Lisp
application does the same as the LIsp system. E.g., Emacs Lisp usually only
enhance the operation of Emacs and relies heavily on the Emacs "machine" to
do its work. Therefore, Emacs Lisp is a scripting language with programming
language capabilities, but its programs could not run without Emacs running
first, and Emacs is a stand-alone application. A Common Lisp system may only
provide the environment for a Common Lisp program but would not do anything
useful by itself. In a sense, it has the same capacity as a shell to launch
applications to run "in" the system, but the same way that the interactive
loop acts as a job control language the way the shell does for Unix programs,
the applications launched from the Common Lisp REPL are as distinct from the
REPL as Unix programs are from the shell.
To refine the distinction I see, a programming language has to assume control
over the execution of the application and terminate execution when it
returns, whereas a scripting language is subject to the control exercised by
another application, which does not necessarily terminate when the script
terminates.
Now, I believe there is a distinction from some deep-rooted sense of there
being a difference in the amount of machinery needed to support a language in
addition to the notion of an intention of the language to be compiled into
native machine code. Another point of view is the intended efficiency of the
resulting code. Scripting languages are not expected to be compiled into
native code that assumes full control over the machine for an extended period
of time and only calls upon the support system, but rather the reverse: a
script is run only occasionally as part of another application that has such
full control.
However, I am sure there are people who consider Common Lisp to be a "glue
language" when they observe that low-level functionality is implemented in C
and the higher-level application is written in Common Lisp.
Duane Rettig
But I contend that these are in fact closely related. And the phobia
goes both ways. Have you ever noticed why people are computer-phobic?
Or have you ever watched a computer-phobe at a computer? They tend to
be overwhelmed, because of course they are too afraid to spend the
requisite time learning how to navigate the computer. They are overwhelmed,
and whenever I watch a computer-phobe try to do something - anything - out
of desperation, in order to accomplish a goal for which this person is
completely overwhelmed, it is I who become afraid for the poor computer.
We had a term in test engineering - the best test machine was the one that
was "gorilla-proof". It's not that we thought of operators on the
manufacturing floor as gorillas, but when we would get a tester back from
there to be repaired, it certainly seemed as if gorillas had been loosed
on the poor tester. This applied both to the physical tester and to the
software as well. Gorilla-proofing involves overbuilding the testers
with interlocks, safety devices, and warnings that are designed to focus
the operator's attention strictly to the task at hand. Similarly, a
tester scripting language restricts the programming (where appropriate)
to those operations related to the test.
> Your first paragraph, talking about
> scripting languages to program tests and test suites on the fly hits the
> nail on the head, imo. You don't want the users of a scripting language
> to be confronted head-on with the full complexity of a conventional
> programming language because they have tasks to accomplish -- which only
> in a subsidiary fashion require programming. Good scripting languages
> provide high-level, succinct tools for doing the things that a user
> needs to do, and put some kind of obstacle (even if only obscurity) in
> the way of doing things completely unconnected to the task at hand.
I agree. This is precisely the case for gorilla-proofing a tester.
> Ideally there should be lots of them, each with a fairly uniform look
> and syntax.
> Eventually, of course, users will want to do things that the originator
> of the scripting language never thought of, or the task (and the machine
> feature set) at hand will change, and then you need a general-purpose
> programming language, and a seamless way of moving between the
> task-specific and fully-expressive modes.
I think that this was precisely Stallman's rationale for choosing a complete
language like Lisp for the scripting language for his editor. He understood
this concept, and realized that there was nothing that wouldn't be tried in
this scripting language, so it might as well be a full programming language.
> If this looks like Greenspun's
> Law yet again, that's because it is, but there's an important twist.
> Those limited, task-specific sublanguages are crucial to actually
> getting the job done -- you don't want' people starting from scratch all
> the time just because it's more elegant.
Yes.
> So every CL program that solves
> a real-world problem ends up containing a buggy, incomplete version of
> some domain-specific scripting language...
I think this is backwards. Usually, for those applications built on CL,
domain-specific languages are built on top of CL, and so its scripting
language already _has_ an implementation (hopefully complete and not
buggy) of CL, or else CL in fact _is_ the scripting language for the
domain-specific app. This is actually ideal, because it gives the
application developer the choice of whether the scripting language for
his app is going to be domain-specific and thus limited in scope (and
potential damage :-) or whether the user will be trusted with a scripting
language that is actually _more_ powerful than the app.
Håkon Alstadheim
> * Erann Gat
> | The argument about whether HTML is or isn't a "programming" language
> | reminded me of something I've been wondering about for a while: is there a
> | useful distinction to be made between "programming" and "scripting"
> | languages? My personal opinon is that there is not, but I'd like to know
> | what others think.
>
> * Michael Sullivan
> | I think there's a distinction, but (a) it's not hard and fast, and (b)
> | scripting is a subset of programming -- they are not completely different
> | things.
>
> Subsets and supersets appear to pose a philosophical problem of some sort. I
One data-point from someone of average intelligence and with only
passing knowledge of Dewey:
I have noticed that "sets" (as in set-theory) and "classes" (i.e. a
set of attributes/attribute-values) form some sort of parallel
notations that are sometimes hard for me to keep straight when I need
to use both.
e.g: (progressing from attributes to set-membership)
A is a name for things that are either red *or* blue.
=>
x is an A -> (x is red) *or* (x is blue)
=>
Any A is in the set of red things *or* in the set of blue things.
=>
The set of red things *and* the set of blue things (union) will
contain all A.
My intuition (i.e. unthinking normal self) will vacillate from one way
of classifying to the other, sometimes mixing both with horrible
results. Note the switch of conjunction from *or* (logical) to *and*
(set-theoretical union).
Now, what does "Lisp is a scripting language and a programming
language" mean? Is it an impossible (always false) statement, or does
it mean something ? If it means something, what does it mean? Lisp has
the "scripting" attribute ? Lisp is a member of the "scripting" class
? Some instance (implementation) of lisp can be used for scripting?
The last one might translate into:
A) some members of the lisp class of languages have the scripting
attribute.
B)some languages with lisp-like attributes exist in the class of
scripting languages.
( C and D follows with all attributes or all class-membership)
--
Håkon Alstadheim, hjemmepappa.
Duane Rettig
> * Erann Gat
> | The argument about whether HTML is or isn't a "programming" language
> | reminded me of something I've been wondering about for a while: is there a
> | useful distinction to be made between "programming" and "scripting"
> | languages? My personal opinon is that there is not, but I'd like to know
> | what others think.
>
> * Michael Sullivan
> | I think there's a distinction, but (a) it's not hard and fast, and (b)
> | scripting is a subset of programming -- they are not completely different
> | things.
>
> This thread puzzles me greatly, so I have to ask a pretty stupid question
> because I realize that I may have an invalid assumption as to what people
> mean by something I have taken for granted for years.
I don't think that it's a stupid question at all.
> If I say that there is a distinction between A and B, I intend to communicate
> that the set of A things and the set of B things are not identical, as they
> would be if there were no distinction between A and B, but this does not
> preclude one from being a subset of the other.
There may be an idiosyncrasy with English at work here. My dictonary defines
the word "distinct" in terms that make sense to me, but which also suggest
a complete disjointedness between the two things which are distinct. However,
the word "distinction" is based more on contrasts in specific areas or dimensional
planes bwteeen two things, rather than total disjointedness.
> Quite the contrary. A subset
> relation is distinctive.
Actually, it is a _proper_ subset which is distinctive. I think we probably
all agree that scripting languages and programming languages have a subset
relationship, but I'm not sure if all agree that that subset relationship
is a proper subset and thus implies distinction.
> I read several responses to this question to mean
> that others would say that there is a distinction between A and B only if no
> A is a B and no B is an A and that a subset relation is /not/ a distinction.
According to my theory, this comes from interpreting the definition of
"distinct", rather than "distinction".
> I take the many responses that people have posted about this to mean that a
> distinction exists between A and B if they are at the same hierarchical level
> in some model or other and that subset relations are a different kind of
> animal altogether. Since I have no other word for this subset relation than
> distinction, I wonder how this works.
I don't think it does, but your theory that each of us approaches the
terminology differently would tend to explain it.
> For instance, one might say that there is a distinction between a computer
> and a personal computer in that a computer is not restricted to one-person
> use, but a personal computer is. Some people here would, I presume, answer
> "no, there is no distinction, personal computers are a subset of computers",
> which does not communicate "there is no distinction" = "they are the same",
> but "there is no distinction" = "subsets are a different kind of not-sameness
> than distinctions". In this model of usage, there would be a distinction
> between a server and a personal computer, because both are refinements of the
> concept "computer" at some notion of the "same level", but there would not be
> a /distinction/ between a computer as the superclass and the server as the
> subclass.
This is a good example of how distinctions can be made on different levels
or for different aspects of two classifications. Anyone who doesn't want
to focus on that aspect for which there is a distinction, simply won't
see a distinction.
> Since we have discussed hierarchical classifications and ontologies lately,
> as well, I wonder if there is not something deeper going on in here that has
> some influence on how people approach classification. It may be useful to
> know that I had first approached classification in libraries before I found
> books about computers in the libary whose math section I had devoured, and
> that I was taught the basic ten classes in Dewey before I was ten myself.
> The reason I brought up Dewey's just recently was that the 5th Norwegian
> edition had been completed and announced with some fanfare in circles I had
> not worked with for several years; yet it occurs me that much of my thinking
> about concepts and ontologies has indeed been shaped by Dewey's in ways I
> have not been fully aware. For instance, a simple concept like an automobile
> could have one classification and the particular kind of automobile known as
> sports utility vehicles another, subordinate to automobiles, but people who
> object to distinction would presumably never classify anything as automobiles
> but would have to classify non-SUVs in a new, separate class and would be
> unhappy to find that there was a category for SUVs but that both other kinds
> of automobiles and automobiles in general had a class that appeared both to
> subsume SUVs and not.
I own an SUV (an Explorer) and I have no misgivings parking in a space
labelled "compact", for two reasons: it fits, and it _is_ a compact SUV!
My wife's car, which is a sports car, is nevertheless much too big to
fit into such a space. To look at them by themselves, though, you would
never classify her car as large, or my car as small.
> The same problem comes up with comp.lang.lisp and
> Common Lisp and Scheme. Some people have strongly objected to requests not
> to discuss Scheme matters in the "general Lisp newsgroup" even though Scheme
> has its own specialized newsgroup, because, presumably, it should be allowed
> since the general category subsumes the more specific. It occurs to me that
> the objections have been over fundamental differences in concept-formation
> and hierarchical organization of knowledge rather than over "is Scheme a
> Lisp?".
Different people will make the distinctions on different levels, and thus
some will not see the same distinctions. Those who feel strongly that they
see distinctions, and those who feel strongly that they _don't_ see
distinctions, will always disagree, and might always argue about it,
even though there is little chance that the others' veiwpoint will be
changed by the argument.
[ other good examples elided ... ]
I think that in communicating distinctions/discriminations/knowledge, it is
always important to include the context for which the communication is
taking place. In the case of making distinctions, where you've demonstrated
that we all tend to fall short of being clear on these, we should be
including the _category_ for which we are trying to distinguish two things,
rather than assuming that everyone here obviously knows on what levels the
distinctions are being made.
> I apologize for the fuzzyiness of the preceding, I realize that I may be
> groping in the dark for the proverbial black cat in the coal cellar that may
> or may not be there.
You will certainly be much more successful groping for that cat, if
it's there, than trying to use your eyes to find it. It would probably
even be more fruitful to just hiss at it, to see if it hisses back...
Pascal Costanza
> The argument about whether HTML is or isn't a "programming" language
> reminded me of something I've been wondering about for a while: is there a
> useful distinction to be made between "programming" and "scripting"
> languages? My personal opinon is that there is not, but I'd like to know
> what others think.
On the wiki, there is a definition for scripting languages that goes
like this. (See http://c2.com/cgi/wiki?ScriptingLanguage)
"A scripting language generally has these properties:
* Source code is present at run time in production system.
* Explicit compilation or linking phases are not needed.
* Variables, functions, and methods typically do not require type
declarations. There are automated conversions or equivalence between types.
* The ability to map external components to the semantics of the
built-in types and/or some component-based protocol (ie. SWIG, OCX, COM)
* Very powerful built-in types - typically a dictionary, a set, a
literal type that can act as either numerics or strings.
* The ability to arbitrarily combine types into heterogeneous structures
* Very powerful iteration semantics map, filter, lambda, etc. (missing
in VB, Tcl, ... )
* You can generate, load, and interpret source code at run time through
an eval function. (Perl, Python, Tcl, shell scripts; missing in VB
* Language interpreter can be embedded within another application,
allowing users to automate application operation, to provide customized
handling of application events, or to define new application functions
using the scripting language."
Can you say "Greenspun"?
However, there is also a continuing debate on the wiki about the
usefulness of this definition...
I don't think you can find a reasonable definition or classification of
scripting languages vs. programming languages. We're dealing with social
phenomena here, and they typically resist certain kinds of "fixed"
definitions.
In Ian Hacking's terminology, scripting/programming langauges are
"interactive kinds" (as opposed to "indifferent kinds", see "The Social
Construction of What?", http://makeashorterlink.com/?R308537D1). Here is
a very abridged version: As soon as you define "scripting language",
programmers will change their own behavior, they will welcome or reject
the definition, and language designers will change their languages based
on that definition, either to support or to attack the definition; so
sooner or later the definition is not valid anymore and needs to be
changed itself.
Hacking calls this interaction between a definition and its
"application" (that changes the definition) "classificatory looping".
This may be frustrating to people who are trained in mathematics or
natural sciences (that mainly deal with indifferent kinds). However, I
am convinced that we have to live with the fact that computer science is
essentially a social science, regardless that it also uses _some_
methodologies borrowed from mathematics.
Pascal
--
Pascal Costanza University of Bonn
mailto:cost...@web.de Institute of Computer Science III
http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)
Barry Margolin
>On the wiki, there is a definition for scripting languages that goes
>like this. (See http://c2.com/cgi/wiki?ScriptingLanguage)
>However, there is also a continuing debate on the wiki about the
>usefulness of this definition...
I can understand that, since Lisp fits almost all the criteria. But
perhaps it would be considered the exception that proves the rule.
Pascal Costanza
> In article <3D89A715...@web.de>, Pascal Costanza <cost...@web.de> wrote:
>
>>On the wiki, there is a definition for scripting languages that goes
>>like this. (See http://c2.com/cgi/wiki?ScriptingLanguage)
[...]
> I can understand that, since Lisp fits almost all the criteria. But
> perhaps it would be considered the exception that proves the rule.
Could be. But then again there is also Smalltalk as another exception.
I rather see it like this. Mainstream programming languages tend to do
two things: (a) They involve some kind of static type system and other
ways to deliberately restrict their expressive power, in order to make
them "safer", more "reliable" and "more efficient". (b) They are
inclined to be used for creating components, i.e. more or less
monolotihic building blocks.
So there's where scripting languages come into play: (a) They are mainly
used for glueing components, and not for developing complete
applications/components. (b) They lack static typing. Obviously people
can live without the "safety", "reliability" and "efficiency"
purportedly provided by static typing, because "it's just the glue".
Again, let me stress that I try to describe the social aspects of these
terms and not their technical merits. And again, I am not 100% sure
because I might have oversimplified things here.
In order to do some kind of reality check: How well is Common Lisp
suited for component-oriented software? My impression is that Common
Lisp (and Scheme) don't provide good means for developing components. Of
course, you can implement CORBA or SOAP wrappers for your applications,
but I guess these things don't feel natural in a Lisp environment. Am I
right? How easy is it to develop, for example, COM components?
Duane Rettig
> Barry Margolin wrote:
> > In article <3D89A715...@web.de>, Pascal Costanza <cost...@web.de> wrote:
> >
>
> >> On the wiki, there is a definition for scripting languages that
> >> goes like this. (See http://c2.com/cgi/wiki?ScriptingLanguage)
>
>
> [...]
>
> > I can understand that, since Lisp fits almost all the criteria. But
> > perhaps it would be considered the exception that proves the rule.
>
> Could be. But then again there is also Smalltalk as another exception.
I'm not sure whether the Smalltalk community have the same problem with
distinctions between scripting languages and programming languages, but
I think that Lisp being suitable for both is precisely the reason that
we have a problem making any distinctions here. If you run down the list
of criteria, you'll find opposing criteria for such explicitly
non-scripting languages like C, Fortran, Cobol, PL/I (I'm listing
languages that were prevalent in the heyday of real scripting languages).
> I rather see it like this. Mainstream programming languages tend to do
> two things: (a) They involve some kind of static type system and other
> ways to deliberately restrict their expressive power, in order to make
> them "safer", more "reliable" and "more efficient". (b) They are
> inclined to be used for creating components, i.e. more or less
> monolotihic building blocks.
I'd prefer not to call them Mainstream languages, but to fit the
distinction closer to their description: compile/link/load/go
languages.
> So there's where scripting languages come into play: (a) They are
> mainly used for glueing components, and not for developing complete
> applications/components. (b) They lack static typing. Obviously people
> can live without the "safety", "reliability" and "efficiency"
> purportedly provided by static typing, because "it's just the glue".
Yes, this tends to be the case where there is a dichotomy of scripting
vs c/l/l/g languages. But in the case of Lisp, there is little
distinction, because Lisp has over the years been able to balance
safety and reliability with speed of prototyping, and so we tend to
ask the question: "what is all the fuss?"
> Again, let me stress that I try to describe the social aspects of
> these terms and not their technical merits. And again, I am not 100%
> sure because I might have oversimplified things here.
I don't think you have.
> In order to do some kind of reality check: How well is Common Lisp
> suited for component-oriented software? My impression is that Common
> Lisp (and Scheme) don't provide good means for developing
> components. Of course, you can implement CORBA or SOAP wrappers for
> your applications, but I guess these things don't feel natural in a
> Lisp environment. Am I right? How easy is it to develop, for example,
> COM components?
Check out http://www.franz.com/products/connectivity_tools/
Many of our customers use CL precisely as a glue, to be able to
salvage many non-homogenous components from the bit bucket and
instead to allow them to work together with our product being the
glue. I doubt that any of these customers would call CL a scripting
language, although some do use it that way. But it can definitely be
used a glue, or as a control or dispatching program for legacy code.
Wade Humeniuk
think of Lisp as a formal language. Whether it is a programming language or
scripting language (or both, or neither) is not what I am looking for. To
enable human beings to work with computers it has become abundantly clear that
it is extremely difficult to get computers to understand unambigously what
humans are saying. Thus it is encumbant for human beings to formalize their
thoughts in the form of a rigorous language. (Humans are much more adaptable at
present). For me this language is Lisp. I can use its external syntax to:
-write a specification
-describe a design
-produce instructions for a computer program
-specify test procedures and run them
-specify rigorous domain specific vocabulary
-communicate ideas to other people
-clarify my thinking to myself
I think there are great benefits in viewing Lisp as a language, instead of the
limited "programming" language classification.
Wade
"Erann Gat" <g...@jpl.nasa.gov> wrote in message
news:gat-160902...@k-137-79-50-101.jpl.nasa.gov...
>
> The argument about whether HTML is or isn't a "programming" language
> reminded me of something I've been wondering about for a while: is there a
> useful distinction to be made between "programming" and "scripting"
> languages? My personal opinon is that there is not, but I'd like to know
> what others think.
>
> Thanks,
> Erann
Joe Schaefer
[...]
> Many of our customers use CL precisely as a glue, to be able to
> salvage many non-homogenous components from the bit bucket and
> instead to allow them to work together with our product being the
> glue. I doubt that any of these customers would call CL a scripting
> language, although some do use it that way. But it can definitely be
> used a glue, or as a control or dispatching program for legacy code.
To me, "scripting language" is a misnomer; I think Tim Bradshaw
had it right earlier in this thread when he associated
"scripting" to a type of *activity* instead of a particular *language*.
I'd roughly define a "script" as something which coordinates the
activities of a complex application, without playing a significant role
in the application's operation itself. I think of it as somewhat
analogous to the "system/application" language (mis)classification,
just moved up one notch.
--
Joe Schaefer
Duane Rettig
> Duane Rettig <du...@franz.com> writes:
>
> [...]
>
> > Many of our customers use CL precisely as a glue, to be able to
> > salvage many non-homogenous components from the bit bucket and
> > instead to allow them to work together with our product being the
> > glue. I doubt that any of these customers would call CL a scripting
> > language, although some do use it that way. But it can definitely be
> > used a glue, or as a control or dispatching program for legacy code.
>
> To me, "scripting language" is a misnomer; I think Tim Bradshaw
> had it right earlier in this thread when he associated
> "scripting" to a type of *activity* instead of a particular *language*.
I guess it depends on how you view the term "scripting language". I've
always viewed the "scripting" part not as a part of the identifier, but
as a capability description.
> I'd roughly define a "script" as something which coordinates the
> activities of a complex application, without playing a significant role
> in the application's operation itself.
I can agree with this view, and as such, Lisp is a scripting language,
because it can run a script.
Consider:
CL-USER(1): (defvar *work* nil)
*WORK*
CL-USER(2): (compile (defun foo () (push 'did-some *work*)))
FOO
NIL
NIL
CL-USER(3): (compile (defun bar () (push 'did-some-more *work*)))
BAR
NIL
NIL
CL-USER(4): (progn
(foo)
(bar)
(reverse *work*))
(DID-SOME DID-SOME-MORE)
CL-USER(5):
Foo and bar are compiled functions (programs - unrelated complex
applications, if you will, for some value of complex), and the progn
is the script. So Lisp is a scripting language (among many other things).
Erann Gat
> * Erann Gat wrote:
> > The argument about whether HTML is or isn't a "programming" language
> > reminded me of something I've been wondering about for a while: is there a
> > useful distinction to be made between "programming" and "scripting"
> > languages? My personal opinon is that there is not, but I'd like to know
> > what others think.
>
> I think that there isn't, and that the distinction is actually
> harmful.
FWIW, this would also be my answer to this question.
It's interesting how many people answered a different question from the
one I actually asked. The question many people are answering in this
thread is: "Is there a distinction between scrtiping languages and
programming languages (and if so what is it)?" But the question I posed
was "Is there a USEFUL distinction?" I think it's pretty clear that there
*are* distinctions (if nothing else, the fact that people make the
distinction is itself a distinction). But whether any of the distinctions
have practical utility is an entirely different question, one to which I
join Tim in answering with a resounding "NO!".
E.
Kaz Kylheku
> Kaz Kylheku [on his shell experiences] :
>
> > That's basically the culture from which Perl emerged...
>
> assessing a culture by a mailing list and a few flames is surely not
> very helpful. just imagine where one may end up from lang.lisp
> for example...
Of course, I have lots of other experiences to draw from. But consider
that Usenet and Unix have a lot of common roots. A comp.unix.shell
newsgroup is sigifnicant in a way that some newsgroup on, say,
airconditioning equipment is not significant to the AC industry.
The fact that I found gross mistakes in the FAQ, and met not one shred
of support for my position from anyone, is an attitude indicator that
cannot be easily dismissed.
In comp.lang.lisp, you *would* find support in advocating correct
programming, rather than opposition in the form of claims that it's
the user's fault for supplying certain kinds of data to the program,
which don't conform to your religious beliefs.
The comp.unix.shell FAQ is *still* broken. Casually scanning through
it, I come upon 2.6:
for f in *.foo; do
base=`basename $f .foo`
mv $f $base.bar
done
It should really be:
for f in *.foo ; do
base="$(basename -- "$f" .foo)"
mv -- "$f" "$base.bar"
done
The backtick syntax is obsolescent; the modern POSIX equivalent is $(
... ). You need to quote the argument to basename, as well as the
expansion, because there could be spaces in the expansion of $f. And
of course $f could expand to something that looks like a command line
option to basename or mv.
None of the comp.lang.* newsgroup FAQ lists I'm familiar with promote
broken solutions that work only part of the time.
Joe Schaefer
> Joe Schaefer <joe+u...@sunstarsys.com> writes:
[...]
> > To me, "scripting language" is a misnomer; I think Tim Bradshaw
> > had it right earlier in this thread when he associated
> > "scripting" to a type of *activity* instead of a particular *language*.
>
> I guess it depends on how you view the term "scripting language". I've
> always viewed the "scripting" part not as a part of the identifier, but
> as a capability description.
That makes sense.
> > I'd roughly define a "script" as something which coordinates the
> > activities of a complex application, without playing a significant role
> > in the application's operation itself.
>
> I can agree with this view, and as such, Lisp is a scripting language,
> because it can run a script.
Yes, I see- thanks alot for cooking up a simple example. Sadly I
actually had to run the progn a few times to make sure I understood it :-)
[...]
> Foo and bar are compiled functions (programs - unrelated complex
> applications, if you will, for some value of complex), and the progn
> is the script. So Lisp is a scripting language (among many other
> things).
What should I do if I wanted to run such a progn as a nightly cron
job? Can I still keep the "script" separate from the "application"?
--
Joe Schaefer
Pascal Costanza
> Pascal Costanza <cost...@web.de> writes:
>>I rather see it like this. Mainstream programming languages tend to do
>>two things: (a) They involve some kind of static type system and other
>>ways to deliberately restrict their expressive power, in order to make
>>them "safer", more "reliable" and "more efficient". (b) They are
>>inclined to be used for creating components, i.e. more or less
>>monolotihic building blocks.
>
>
> I'd prefer not to call them Mainstream languages, but to fit the
> distinction closer to their description: compile/link/load/go
> languages.
Oh yes, sure - sorry for that. I meant "language that get lots of
publicity these days", or something along these lines. They happen to be
c/l/l/g languages.
>>In order to do some kind of reality check: How well is Common Lisp
>>suited for component-oriented software?
[...]
> Check out http://www.franz.com/products/connectivity_tools/
Yes, that's an impressive list of features!
Erann Gat wrote:
> In article <ey3y9a1...@cley.com>, Tim Bradshaw <t...@cley.com> wrote:
[...]
>>I think that there isn't, and that the distinction is actually
>>harmful.
>
> FWIW, this would also be my answer to this question.
>
> It's interesting how many people answered a different question from the
> one I actually asked. The question many people are answering in this
> thread is: "Is there a distinction between scrtiping languages and
> programming languages (and if so what is it)?" But the question I posed
> was "Is there a USEFUL distinction?" I think it's pretty clear that
there
> *are* distinctions (if nothing else, the fact that people make the
> distinction is itself a distinction). But whether any of the
distinctions
> have practical utility is an entirely different question, one to which I
> join Tim in answering with a resounding "NO!".
Well, I still like the discussion, even though we are answering the
wrong questions. ;-)
I have an idea: Perhaps it's better not to talk about whether there is a
useful _distinction_ between scripting languages and "ordinary"
languages. In fact, scripting languages are a useful _addition_ to
"ordinary" languages, if these ordinary languages happen to be c/l/l/g
languages. Obviously, programmers need the kind of flexibility the
additional features provide. The discussion (and the distinction) is
useless in the context of Lisp because Lisp provides these features
right away.
Again, perhaps this is going in the wrong direction. Today, I have asked
a colleague of mine who hasn't (yet ;) adopted the Lisp mindset how he
would define the term scripting languages. He said that the
distinguishing feature is that a script is actually a text file. So for
example, he would regard DOS batch files as scripts, and therefore the
DOS command set as a scripting language.
Pascal
Duane Rettig
I'm not sure what you mean by "separate". A nice aspect of Lisp
is that it can be invoked once and several different applications
loaded and run (including scripts) within the one process, or it
can house individual applications , each in different Lisp invocations.
If you really are running cron specifically, then the script might
be a Lisp invocation that talks to other Lisps through an IPC or
by some other means, or else the script might start up and then
load the other Lisp application(s) into the same process, or perhaps
the Lisp is already started, and the cron job simply alerts the script
to run via an interrupt, IPC call, or by any other means you choose.
Another way to run it is to take a Lisp-is-the-operating-system
approach; the Lisp always stays running, and an application that is
equivalent to cron (only written in Lisp) invokes the script, which
in turn runs each application (still within the same lisp invocation).
Joe Schaefer
> Joe Schaefer <joe+u...@sunstarsys.com> writes:
[...]
> > What should I do if I wanted to run such a progn as a nightly cron
> > job? Can I still keep the "script" separate from the "application"?
>
> I'm not sure what you mean by "separate".
The script and the application often follow separate, uncoordinated
development tracks. I don't want to dump the script and the
application into a single executable file just to run the script.
I also don't want to write a shell script in order to run the
lisp script.
I picked cron arbitrarily, but in retrospect that was a poor
example. Something like
0 1 * * * /path/to/cmu/lisp -load /my/script.lisp -eval \(quit\)
will do what (I think) I want.
Nevertheless, I'm sure you've answered the question that I should
have asked. Now I just have to figure out what that question is :-)
Thanks again.
--
Joe Schaefer
Frank A. Adrian
> I think there's a distinction
Of course there is. I use a scripting language when I script and a
programming language when I program. Although since I never script, but
always program, it doesn't matter, anyway...
faa
Vassil Nikolov
> The argument about whether HTML is or isn't a "programming" language
> reminded me of something I've been wondering about for a while: is there a
> useful distinction to be made between "programming" and "scripting"
> languages? My personal opinon is that there is not, but I'd like to know
> what others think.
Interesting that no one has mentioned REXX in this thread.^1 I
believe that for a reasonable meaning of `scripting,' which is
different from the meaning of `programming,' REXX represents the
ultimate in scripting. It has a reasonably complete set of
language constructs *and* the primitives of whatever environment
the REXX program is running in. (If it is the `shell' (CMS), then
all operating system commands are available; if it is the editor
(XEDIT), then all editor commands, and so on. In fact, it is also
possible to switch the environment during execution.) If I call
writing in REXX `programming,' that would be for a different
meaning of programming than (say) writing in C, which kind of
represents the ultimate in non-scripting.
_________
^1 AppleScript was mentioned indeed, but REXX predates it
significantly, and is in my opinion more powerful
It's hard to place a simple and unambiguous label on Common Lisp
from the above point of view. It is a true and sophisticated
programming language, and at the same time it is easy to imagine it
used in the same way as REXX in a multitude of co-existing
environments (in fact, wasn't it used like that in Lisp machines?).
On the other hand, I cannot see C (or any Algol-like language) in
REXX's role at all. But maybe Common Lisp is the exception to the
rule, as another poster suggested.
By the way, the mainframe world offers another, older example: JCL
is a scripting language but not a programming language, isn't it?
(Please note that this is quite independent of the question if it
is an awful language or not...)
I guess the simplest (and grossly simplified) rule of thumb I can
think of is: if, even for the simplest executable unit in the
language, some sort of enclosing syntactical delimiters are
mandatory (like ``begin'' and ``end''), then it is a non-scripting
language; if merely concatenating simple expressions/statements in
the language produces an executable unit, then it can qualify as a
scripting language. In other words, my intuitive understanding of
the distinction is based at least to some extent on the syntax,
specifically the minimum amount of syntax that makes a valid
program or script.
* * *
More philosophically speaking, and in a different line of thought,
I believe that scripting is one step off programming in the
direction towards planning. What I have in mind is that the main
difference between a plan and a program (or at least one of the
main differences) is that a program is to be executed by a machine
while a plan is to be executed by an intelligent entity. (A plan
is always underspecified and does not provide courses of action for
almost all of the infinitely many abnormal situations that may
occur, yet its execution is expected to succeed where machine
execution of a program would `produce undefined results.') Or to
borrow the example quoted by Kaz Kylheku for a simple illustration,
for f in *.foo; do
base=`basename $f .foo`
mv $f $base.bar
done
has more the scripting nature, while
for f in *.foo ; do
base="$(basename -- "$f" .foo)"
mv -- "$f" "$base.bar"
done
has more the programming nature, as the former is less burdened
with provisions against undefined results (with the advantage of
making the essence of what is being done more conspicuous), at the
expense of requring more intelligence by the user to avoid applying
it to a situation where it may fail, or to watch for failure and
possibly take corrective action.
---Vassil.
Duane Rettig
> Duane Rettig <du...@franz.com> writes:
>
> > Joe Schaefer <joe+u...@sunstarsys.com> writes:
>
> [...]
>
> > > What should I do if I wanted to run such a progn as a nightly cron
> > > job? Can I still keep the "script" separate from the "application"?
> >
> > I'm not sure what you mean by "separate".
>
> The script and the application often follow separate, uncoordinated
> development tracks. I don't want to dump the script and the
> application into a single executable file just to run the script.
> I also don't want to write a shell script in order to run the
> lisp script.
You could always separate your applications into fasl files. Then,
when they are needed, just load them in. The script could be in a source
file, but it's also easy enough to compile as well. This is part of
the problem Lispers have of separating scripting and programming
languages; we have all of it in one language!
> I picked cron arbitrarily, but in retrospect that was a poor
> example. Something like
>
> 0 1 * * * /path/to/cmu/lisp -load /my/script.lisp -eval \(quit\)
>
> will do what (I think) I want.
Yes. It depends on how heavyweight your lisp is (i.e. how much memory
it takes and how long it takes to start). That used to be a problem,
but I don't think it is anymore - most lisps start in small fractions
of a second.
> Nevertheless, I'm sure you've answered the question that I should
> have asked. Now I just have to figure out what that question is :-)
> Thanks again.
You're welcome.
Erik Naggum
| It's interesting how many people answered a different question from the one
| I actually asked. The question many people are answering in this thread is:
| "Is there a distinction between scrtiping languages and programming
| languages (and if so what is it)?" But the question I posed was "Is there a
| USEFUL distinction?"
I believe most people would want to know what the distinctions are before
they judge them useful or not. A priori usefulness tend not to exist, so
the obvious answer to the question is "no" /before/ one does careful study.
Joe Marshall
> Or to borrow the example quoted by Kaz Kylheku for a simple
> illustration,
>
> for f in *.foo; do
> base=`basename $f .foo`
> mv $f $base.bar
> done
>
> has more the scripting nature, while
>
> for f in *.foo ; do
> base="$(basename -- "$f" .foo)"
> mv -- "$f" "$base.bar"
> done
>
> has more the programming nature, as the former is less burdened
> with provisions against undefined results (with the advantage of
> making the essence of what is being done more conspicuous), at the
> expense of requring more intelligence by the user to avoid applying
> it to a situation where it may fail, or to watch for failure and
> possibly take corrective action.
So a script is a program written by an amateur?
Erik Naggum
| So a script is a program written by an amateur?
Would it not be called just a "gram" then?
Christopher Browne
> * Joe Marshall <j...@ccs.neu.edu>
> | So a script is a program written by an amateur?
>
> Would it not be called just a "gram" then?
If you get a thousand of them, that's called a "kilogram."
--
(reverse (concatenate 'string "moc.enworbbc@" "sirhc"))
http://cbbrowne.com/info/languages.html
"I'm sure that nobody here would dream of misusing the Arpanet. It's
as unthinkable as fornication, or smoking pot." -- RMS
Lieven Marchand
> Interesting that no one has mentioned REXX in this thread.^1 I
> believe that for a reasonable meaning of `scripting,' which is
> different from the meaning of `programming,' REXX represents the
> ultimate in scripting. It has a reasonably complete set of
> language constructs *and* the primitives of whatever environment
> the REXX program is running in. (If it is the `shell' (CMS), then
> all operating system commands are available; if it is the editor
> (XEDIT), then all editor commands, and so on. In fact, it is also
> possible to switch the environment during execution.) If I call
> writing in REXX `programming,' that would be for a different
> meaning of programming than (say) writing in C, which kind of
> represents the ultimate in non-scripting.
Now that's a blast from the past. In fact, in VM/CMS your application
could define its own environment and then load in REXX scripts that
used this environment.
ObCL: it's 'procedure ... expose' parameter passing gives you the same
choice between lexical and dynamic scope as CL.
--
Hai koe, zei de stier,
Kom mee met mij in de wei,
Dan zijn we tweezaam.
Lieven Marchand <m...@wyrd.be>
Vassil Nikolov
I would say a script is lighter than a program. And I have seen
programs written by amateurs (or alleged professionals) that were
pretty heavy, only in the wrong way...
---Vassil.
Vassil Nikolov
> * Joe Marshall <j...@ccs.neu.edu>
> | So a script is a program written by an amateur?
>
> Would it not be called just a "gram" then?
An erogram (rather than an amagram), maybe?
(Not to be confused with errorgram...)
---Vassil.
Joe Marshall
Between the two examples above, I'm not sure I see a difference in
`weight', only a difference in rigor. The first program is very
sloppy with regard to quoting while the second is not.
Julian Fondren
> Kaz Kylheku [on his shell experiences] :
>
> > That's basically the culture from which Perl emerged...
>
> assessing a culture by a mailing list and a few flames is surely not
> very helpful.
What makes you think he did that? My first edition "Learning Perl" has
an intro by Larry Wall that supports the assertion you quote.