Lambda the Ultimate

Why not use an off-the-shelf scripting engine that embeds into your java project?

I second this. There are a number of script interpreters available as Java libraries, include Javascript (Rhino), Beanshell (an interpreted Java dialect), Jython, various Schemes (SISC, JScheme, Kawa), and the list goes on, literally, on the Programming Languages for the Java VM page.

I've used Beanshell, Rhino Javascript, and SISC Scheme for this purpose on various occasions. They're all easy to integrate. You can pick one based on the likely tastes of the people who will be using it. Beanshell is good if you want to stick to Java syntax.

Developing one's own new language makes little sense, unless the goal is to write a new language rather than get some other job done.

Let's all just drop the term "scripting language". It might have been a useful designation years ago, but no solid definition exists today that contains Perl/Python/Ruby without covering C/Java/ASM.

IMHO, the best definition is "whatever language you get real work done in", which could potentially cover C or Java. I'm OK with that, but a lot of people aren't.

Let's also please drop "compiled" and "interpreted" since we're in a world of straight interpreters, bytecode compilers without just-in-time compilation, bytecode compilers with just-in-time compilation, interactive compilers that go straight to native code, multi-stage languages where the entire "phase distinction" is blurred...

I've been rolling my eyes for over a decade now whenever someone has described Lisp as "an interpreted language."

In that case, we should also drop the informal word "reflective", since every programming language can serve as its own metalanguage. Are you amenable to this, I wonder?

..whether there are reflective languages in the sub-Turing complete neck of the woods? There used to be some interest in PLs whose type system would only pass provably-terminating programs. Monadic computational lambda-calculus? Lambda-calculus with strong intersection types (ie. no omega type)?

...and I think an important one, because it reminds me of the difficulty of these categorizations absent some discussion of whether we're talking about the language in the context of its interpreter/compiler only, or in the context of a presumably more expressive build system, in which "metaprogramming on the cheap," e.g. manipulation of source code via sed scripts etc., is relatively common. I'm also reminded of Skaller's observation that the only way a build system can be truly general-purpose is if it keeps re-evaluating dependencies and rebuilding unsatisfied dependencies until it reaches a fixed point. Hmmmm.

...there was a useful distinction (between "scripting" and "non-scripting" languages) that nobody has mentioned, and which has little to do with type systems, interpreted vs compiled, or OO-ness.

That distinction is:

* A scripting language is one which provides abbreviated syntax for such things as I/O and I/O redirection, process creation and job control, file and directory manipulation, text processing, and such.

* A non-scripting language is one which provides abbreviated syntax for arithmetic and similar operations.

Modern languages do blur this distinction quite a bit. But a property of many older scripting languages (Bourne shell, etc.) is that it is far easier to get a directory listing in 'em then it is to add a pair of numbers.

A scripting language is one which provides abbreviated syntax for such things as I/O and I/O redirection, process creation and job control, file and directory manipulation, text processing, and such.

I'd say that I/O redirection, process creation and job control are particular to shell languages, but then I don't think that shell languages are a special case of scripting language.

• Scripting languages: Python, Ruby
• Shell languages: Perl, in this case with a few bells and whistles
• For compilation programming languages: C, ASM
• For interpretations programming languages: Java

So, IMO, it would appear that part of the mistake would be either in thinking that Perl is a scripting language, or in thinking that shell languages are scripting languages.

<imho>

"Scripting" is a style of programming (a subset) that has two properties:

• Your usually telling an external object what to do through a simple/minimal interface.
• The control flow is fairly sequential.

Both of these properties also apply to the script of a play (which could be where the term came from).

So when you write a Bash script that uses 'tar', 'gz', 'diff', and 'scp' to make a backup of your files and copy them somewhere, you're probably scripting. If you use Bash to parse and convert a Unix-ish command line into a Windows-ish command line (cyg-wrapper.sh), then its not scripting anymore.

The term "scripting language" is a derived definition that means "a language that is best for scripting". I would consider Bash to be a scripting language. Perl is on the border. I think Python and Ruby are less optimized for scripting. I totally agree that neither Python, Ruby, nor Perl should still be called scripting languages. (They should be called recklessly-typed languages :)

</imho>

I would broadly agree with this.