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 # that's write, this next while statement actually opens (and closes) each file in turn # reading a line for each run through the loop, ending when all lines are exhausted. while (<>) { # that's right. $_ holds the current line so you don't even have to declare a variable, # but you could if you wanted to by typing 'while ( $line = <> )' strip(); # cut off newline; assumes $_ if nothing presented # grab everything up to the equal, then after the equal # put both in the array 'pair' 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