www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Scripting languages

reply Georg Wrede <georg.wrede nospam.org> writes:
Of course, scripting languages say "the program is the
text file, so sources never get lost".

What other reasons do people have for using them?
What's the opinions you guys hear?
Feb 18 2005
next sibling parent Sebastian Beschke <s.beschke gmx.de> writes:
Georg Wrede schrieb:

 Of course, scripting languages say "the program is the
 text file, so sources never get lost".
 
 What other reasons do people have for using them?
 What's the opinions you guys hear?


IMHO, there is no clear distinction between scripting languages and 
other languages. Some languages work using an interpreter, some are 
compiled. However, one could possibly write a C++ interpreter too, and 
there are compilers for many "scripting" languages.

The important thing is what kind of high-level concepts the language 
offers and how this affects runtime performance. E.g., most "scripting" 
languages are relatively slow, compared to C++ or D. But code is often 
more elegantly expressed in Python or Ruby than in C++ or even D (Ds 
static typing system may be a debugging aid, but adds verbosity). This 
is actually part of the point - the less words you use in a language, 
the more "scripting" it is.

All of this is my opinion, of course. ^^

-Sebastian
Feb 18 2005
prev sibling next sibling parent reply Norbert Nemec <Norbert Nemec-online.de> writes:
Georg Wrede schrieb:

 Of course, scripting languages say "the program is the
 text file, so sources never get lost".
 
 What other reasons do people have for using them?
 What's the opinions you guys hear?


One of the key features of scripting languages is that you can use them 
interactively. One of the best examples is python with its excellent 
shell 'ipython'.

Of course, you never do big projects interactively, but for trying out 
code-snippets or testing code that you are writing in a source-file, an 
interactive command line is just optimal.

Furthermore, an interactive interface is a great thing for tasks like 
data-processing or ad-hoc calculations. You can also combine it with 
other interfaces like a GUI and have the full power of the whole 
language at your fingertips.

I've always dreamed of a language that could be used interactively as 
well as compiled for high performance. So far, OCaml is the only 
language I know of that really is designed to offer this. Most scripting 
languages cannot be compiled efficiently by design and most compiled 
languages cannot be easily interpreted and executed line by line.

Maybe, one could investigate something like interactive-D ? Hopefully in 
such a way, that it stays the same language without artificial restrictions.
Feb 18 2005
parent reply zwang <nehzgnaw gmail.com> writes:
Norbert Nemec wrote:

 I've always dreamed of a language that could be used interactively as 
 well as compiled for high performance. So far, OCaml is the only 
 language I know of that really is designed to offer this. Most scripting 
 languages cannot be compiled efficiently by design and most compiled 
 languages cannot be easily interpreted and executed line by line.
 
 Maybe, one could investigate something like interactive-D ? Hopefully in 
 such a way, that it stays the same language without artificial 
 restrictions.


You might find Ch interesting.
"Ch is an embeddable C/C++ interpreter for cross-platform scripting, 
shell programming, 2D/3D plotting, numerical computing, and embedded 
scripting. C/Ch/C++ allow users to use one language, anywhere and 
everywhere, for any programming tasks."

(quoted from http://www.softintegration.com/)
Feb 18 2005
parent Norbert Nemec <Norbert Nemec-online.de> writes:
zwang schrieb:

 Norbert Nemec wrote:
 

 I've always dreamed of a language that could be used interactively as 
 well as compiled for high performance. So far, OCaml is the only 
 language I know of that really is designed to offer this. Most 
 scripting languages cannot be compiled efficiently by design and most 
 compiled languages cannot be easily interpreted and executed line by 
 line.

 Maybe, one could investigate something like interactive-D ? Hopefully 
 in such a way, that it stays the same language without artificial 
 restrictions.


 
 
 You might find Ch interesting.
 "Ch is an embeddable C/C++ interpreter for cross-platform scripting, 
 shell programming, 2D/3D plotting, numerical computing, and embedded 
 scripting. C/Ch/C++ allow users to use one language, anywhere and 
 everywhere, for any programming tasks."
 
 (quoted from http://www.softintegration.com/)


Thanks for the hint. Interesting to know about it.
Feb 19 2005
prev sibling next sibling parent "Charlie Patterson" <charliep1 SPAMIDDYSPAMexcite.com> writes:
From: "Georg Wrede" <georg.wrede nospam.org>


 I was wondering what kinds of arguments against other
 languages the Perl people usually use in office arguments?

 Or, put another way, if D or some other language has
 decent regexps, then what other issues these people
 cite for not using those languages?


There are endless features in Perl for writing short, text-processing apps,
which is what
it is meant for (Practical Extraction and Reporting Language).  There is a
culture in Unix
(where culture is a good word here and not a "religious rite" type word) that
dates back
to Unix's original use: creating output as batch jobs and parsing those
results, working
with config files for a network, etc.

Suppose you want to write a command that works a lot like "grep": opens a
series of files,
and parses them as lines.  But your lines will all be "key = value" and you
want to work
with that data.  In C/C++/D this would require an opendir, then an fopen per
file, reading
the line and using string functions (strchr, etc in C) to try and parse it. 
This is all
condensed into a "calculus" in Perl like so:

    example: calculate file1 file2 file3


file in
turn

exhausted.
    while (<>)
    {

declare a
variable,






         pair = $_ ~= /(.*)=(.*)/;

        $key = pair[ 0 ];
        ...
    }

Now if you didn't need all the comments, that would be insanely short code to
do all that
I mentioned!

However this is the kind of thing Perl was to do.  It *has* functions, but they
are very
simple.  Long programs will get messy quickly.  In Perl 5 they added more
function syntax,
modules, objects and all sorts of stuff but they realized it was hopelessly
complex, I
think.  So they are simplifying for Perl 6.

For a history of how this came about you should read up on 'grep', experiment
with it,
then 'sed', experiment, then 'awk', experiment, and finally perl.  Those other
programs
are much smaller, but the progression for text processing will become clear.
Feb 18 2005
prev sibling parent "Charlie Patterson" <charliep1 SPAMIDDYSPAMexcite.com> writes:
From: "Georg Wrede" <georg.wrede nospam.org>

 Of course, scripting languages say "the program is the
 text file, so sources never get lost".

 What other reasons do people have for using them?
 What's the opinions you guys hear?


Scripting languages usually have "dynamically typed" variables

    $a = 1;
    $a = "hello";  // OK.  Just changed type
    $a = "hello" + 2; // actually works in some langs.  just cast strings to 0.

They also usually allow you to write dynamic code:

    $c = "foo(1);" // just a string
    echo $c; // show it
    eval $c // actually run c;
    $d = readln($stdin); // user types "junk(][!!";
    eval $d; // running user input, but a syntax error will result.
    // notice how insecure the above could be!  user could have typed "rm *" or
"cat
/etc/passwd"

Note that between these two features, it's hard to write a compiler for an
interpreted
language.  Dynamic typing requires you to keep around a symbol table because
the types
change over time, and "eval" requires you to write an interpreter into the
compiled
program anyway because you never know what the string will be.  Between these
two, you'll
mostly still have an interpreter compiled into your code!

----

Next, good 'ol scripting languages rarely looked like normal procedural
languages.
Nowadays, you'll have, in Perl, etc:

    $a = cos( $b / 2 );

which looks like C with dollars in it.

For old school, check out "sh" on Unix (or ksh or csh).  What you'll find is a
"glue"
language that just routes files in and out of other executables.  It needs
minimal
branching and looping to qualify, but it doesn't know about opening files or
even
expressions.

    $a = 3 + 2 // nope. it will say, "can't find program '3'"
    $a = expr 3 + 2 // actually called a program 'expr' to do any math. sent in
3, +, and
2 as params

    // $count holds result of 'wc' program. can't write 'wc' (word count)
equivalent in sh
language.
    $count = `wc -l $file`

    // OTOH, this is pretty powerful
    echo "all refs from digitalmars.com: "
    grep digitalmars.com http.log | wc -l

    So "sh" provides the piping and even concurrent processing,  and lots of
text-processing apps provide the guts.  "sh" is very domain specific and not
good at all
for math or graphics or databases, etc.  There are lots of "scripting"
languages nowadays
that are really just interpreted languages stealing the name.

----

Finally the $ thing is from "sh" and I wish it would go away!  I guess shell
scripts are
short enough that there aren't many variables anyway, and $ is useful for
printing:

    echo "Hello $name and welcome back to $host."

But scripts of any size get really ugly really fast: $a += $b * 3.  I wish Perl
hadn't
done this and I've never figured out why it did!
Feb 18 2005