Liste des Groupes | Revenir à cu shell |
At one time, we distinguished between “scripting” languages andI don't think there has ever been a clear distinction.
“programming” languages. To begin with, the “scripting” languages were
somehow more limited in functionality than full-fledged “programming”
languages. Or they were slower, because they were interpreted.
Then languages like Perl and Java came along: both were compiled to aSuch classification is just wrong, IMHO. You can write scripts in Perl, and you can write programs in Perl. "APL" is invariably (AFAIK) interpreted, and it is for programming rather than scripting - the acronym stands for "A Programming Language".
bytecode, a sort of pseudo-machine-language, which was interpreted by
software, not CPU hardware. Were they “scripting” or “programming”
languages? Some might have classed Perl as a “scripting” language to
begin with, but given it is must as powerful as Java, then why
shouldn’t Java also be considered a “scripting” rather than
“programming” language? And before these two, there was UCSD Pascal,
which was probably the pioneer of this compile-to-bytecode idea.
So that terminology for distinguishing between classes of programmingI am not at all convinced it was ever relevant to distinguish between "scripting languages" and "programming languages". It was useful to distinguish between "interpreted" and "compiled" languages, and the overlap and blurring has increased there.
languages became largely obsolete.
But there is one distinction that I think is still relevant, and thatThat is arguably a useful distinction in the style of programming languages, and this difference makes the language more or less suited to particular tasks (such as typical short scripts).
is the one between shell/command languages and programming languages.
In a shell language, everything you type is assumed to be a literal
string, unless you use special substitution sequences. E.g. in a POSIX
shell:
ls -l thingy
“give me information about the file/directory named ‘thingy’”, vs.
ls -l $thingy
“give me information about the files/directories whose names are in
the value of the variable ‘thingy’”.
Whereas in a programming language, everything is assumed to be a
language construct, and every unadorned name is assumed to reference
some value/object, so you need quote marks to demarcate literal
strings, e.g. in Python:
os.listdir(thingy)
“return a list of the contents of the directory whose name is in the
variable ‘thingy’”, vs.
os.listdir("thingy")
“return a list of the contents of the directory named ‘thingy’”.
This difference in design has to do with their typical usage: most of
the use of a shell/command language is in typing a single command at a
time, for immediate execution. Whereas a programming language is
typically used to construct sequences consisting of multiple lines of
code before they are executed.
This difference is also why attempts to use programming languages as<https://en.wikipedia.org/wiki/List_of_programming_languages_by_type> gives something like 40 categories of programming languages, of which "scripting languages" is one type. I think any attempt at dividing up programming languages will either be so full of grey areas as to be almost useless, or have so many categories that it is almost useless. The best you can do is pick some characteristics of languages, or some typical use-cases of languages, and ask if any given language fits there.
though they were shell/command languages, entering and executing a
single line of code at a time, tend to end up being more trouble than
they are worth.
Conversely, using shell/command languages as programming languages, by
collecting multiple lines of code into shell scripts, does work, but
only up to a point. The concept of variable substitution via string
substitution tends to lead to trouble when trying to do more advanced
data manipulations.
So, in short, while there is some overlap in their applicable usage
areas, they are still very much oriented to different application
scenarios.
Les messages affichés proviennent d'usenet.