Script Vs Java

We have a product that comes with its own proprietary scripting language. This scripting language runs inside a JVM and can callout to java classes. Like most of the scripting languages, this script is not object oriented. I am concerned about using this scripting language for heavy programming. This scripting code can only be stored in a database. It is hard for multipel developers to work on it simultaneouly. I am afraid of facing significant maintenance issues in the future.

Before it becomes too late, I am thinking to write the code in java and call from this scripting language.I am interested in comparing the advantages/disadvantages of using a proprietary scripting language against using Java. Please give me your thoughts so I can make a better decision.

I really appreciate your input..

Thanks
Rajesh

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Why not use an off-the-shelf

Why not use an off-the-shelf scripting engine that embeds into your java project? You can even use an interpreter for java that embeds into java programmes.

Agreed

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.

non-sense...

"Like most of the scripting languages, this script is not object oriented."

Yeah, right. Ruby, Python, Javascript or Groovy sure can't please you for not being OO...

More non-sense

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.

Amen!

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."

And "reflective"

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?

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)?

Interesting Question...

...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.

In years past...

...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.

scripting vs. shell

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.

My classification

  • 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.

Scripting is a style of programming

<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 th

I would broadly agree with this.

Surely the definition of "scr

Surely the definition of "scripting language" is that it is intended for controlling or customising the behaviour of a host system without requiring any external development environment? This definition still applies to most languages that are considered "scripting"; those that are not tend to require a little bit more jiggery pokery faffing with including compilers in the host application than for a scripting language.