Artima.com has published a short article that recommends that programmers who use a systems language learn a scripting language too.---xj40dkcfea73---Artima.com has published a short article that recommends that programmers who use a systems language learn a scripting language too.

http://www.artima.com/commentary/langtool.html

Here's an excerpt:

To me, attempting to use one language for every programming task is like attempting to use one tool for every carpentry task. You may really like screwdrivers, and your screwdriver may work great for a job like inserting screws into wood. But what if you're handed a nail? You could conceivably use the butt of the screwdriver's handle and pound that nail into the wood. The trouble is, a) you are likely to put an eye out, and b) you won't be as productive pounding in that nail with a screwdriver as you would with a hammer.

Because learning a new programming language requires so much time and effort, most programmers find it impractical to learn many languages well. But I think most programmers could learn two languages well. If you program primarily in a systems language, find a scripting language that suits you and learn it well enough to use it regularly. I have found that having both a systems and a scripting language in the toolbox is a powerful combination. You can apply the most appropriate tool to the programming job at hand.

What's your opinion?

The tool/product analogy is unfortunate, because it doesn't capture a critical element of software development (as it is today :) - the tool you use, is also the product itself. It will have an effect on the entire lifecycle of the product, not just building it.

I use both scripting and strongly typed languages and generally find I make less mistakes in strongly typed languages and therefore favour these.

One interesting alternative is type inferring languages, e.g.:

http://www.haskell.org/

Type inferring languagesare less verbose than strongly typed languages but still type check. You need to define method argument types and return types but generally not variable types, they are inferred, e.g.:

x = 1;

the language would infer that

x

was of type

int

and if you did:

x = 'a';

this would be an error since

x

is an

int

.

Another more complicated example is:

class Example {
    x;
    Example(int x) { this.x = x; }
}

would infer that field

x

is of type

int

from its use inside the constructor, note the constructor argument is typed.

What do you think, do you like typing inferring?

Note I have used Java like syntax in the examples above; the syntax of type inferring languages is generally more Python like, e.g. Haskell.

I think inferring types is a great technique, because it yields less finger typing, and less code to look at, but not I suspect in a way that makes the code cryptic.

Nevertheless, I think I would be inclined to apply a type-inferrence language in the same way I use Java right now, to build things. When it comes to doing quick little jobs that require code, such as processing strings in files, I don't feel the need for statically typed variables.

So what is the argument against using a scripting language to build a "system"? I've been loosely following the articles on this site, and I haven't heard a strong argument for not just using a language like Python to build a system.

And since you could build a system out of a scripting language, would that make a scripting language a system language as well?

Also, is a scripting language dynamically typed by definition?

I think it is important to facilitate also the maintenance of a system.

If I a have a system that is a patchwork of HTML, JavaScript, Java and some proprietary regex-like command line scripts, with business logic dispersed throughout the system, I have very likely created a system that is hard to maintain.

I find it to be really helpful and important to have a solid and wide toolset at hand as individual developer, but it must be applied with care.

In the corporate environment sometimes sticking with some standard (but deliberately limited) toolset must be enforced.

My 2c.

Scripting languages may not be a good choice for anything beyond small to medium sized tasks.

One issue that is rarely mentioned is that it is very hard to create tools for working with the code itself. Consider the support for refactoring:

Example: A class Order has a method check(). This method needs to be renamed (or its signature changes etc). Thanks to strong typing, editors such as Eclipse or IDEA are able to automatically fix any references to the changed method. On the other hand it is not possible for a Python editor to know whether it may safely modify the following function:

  def f(order):
    order.check()

Of course I strongly agree that scripting languages are the preferred tool for small tasks, unless you have too many programmers that need to be kept busy :-) A very effective approach is to develop the core of your application in Java, and use Jython for small day to day tasks (you can transparently use your Java classes). Perhaps every future language (or platform, more accurately) should support at least two syntaxes, full-blown and scripting level. (For certain applications a third, low level syntax might also be usefull.)

An acquaintance of mine who is an experienced C++ engineer and who is a Perl fanatic, developed a distributed payment system a few years back that's still in daily operation.

Obviously he used C++ to develop such a system, right?
Nope :) He wrote it in Perl.

His motivation was the speed of development that it facilitated, and he wrote it according to OO principles- not sure if he used OO Perl or just designed it that way.

He did say that this approach would only work with a small development team (which was the case here, 3 or 4 developers) because it would be impossible to enforce standards in a large team. I also suspect that only he or his team could successfully maintain the subsequent code.

This highlights to me the trade-off between speed of development and maintainability of scripting languages.

I don't know enough about Python yet (although I'm impressed by what I've read) but I'd be nervous about using a language like Perl for a major project.

I use Perl for day to day tasks (mostly regex and file-parsing), Java for system development. Going back to Java code after a few months, or looking at someone else's code, I can quickly pick up what's there in front of me.
With Perl, even with a one file program, it takes me a good bit longer. However, I don't use Perl as much as Java

I love Perl, and I'd be happy to see a language like Python become a de-facto systems development language. Speed of development and ease of use are all good things. But maintainability has to be part of the package. Perhaps it already is...

What scripting language would be a good one for a Java programmer to start on? The three I hear mentioned most these days are Perl, Python, and Ruby... I've dabbled a bit in all three but not enough to get a strong grasp on what the day-to-day advantages are between one and the next. It does seem to me that Python and Ruby are more readable than Perl, and Ruby professes to be more purely object oriented than Python.

However, from a Java programmer's point of view who only is interested in taking "short hikes" with these languages, it seems like the main goal should be speed of development and not necessarily OO purity or readability. And Perl's ubiquity on Unix systems is hard to ignore. However, I also heard that Perl 6 will be a ground-up overhaul of the language...?

Thoughts?

> So what is the argument against using a scripting language
> to build a "system"? I've been loosely following the
> articles on this site, and I haven't heard a strong
> argument for not just using a language like Python to
> build a system.
>
Well, there are at least two schools of thought. The strong-typer's view is that you can't get as robust an end product without strong static type checking at compile time. The weak-typer's view is that you can get as much robustness through testing, and that you get to start testing sooner. I have attempted to publish both sides of this argument on Artima.com so that readers can judge for themselves (and discuss the issue with each other in this forum).

For the quickest overview of the debate, check out page one of the Strong versus Weak Typing installment of the Guido van Rossum interview:

http://www.artima.com/intv/strongweak.html

On that page, I present Guido with quotes from earlier interviews with James Gosling and Josh Bloch in which they give the strong-typer viewpoint. Links to the interviews containing those quotes are available in the resources section of the Van Rossum interview:

http://www.artima.com/intv/strongweak4.html#resources

So in short, the answer to your question is that there isn't a consensus in the industry. In the Use the Appropriate Tool for the Job article, I describe the ways in which I apply systems and scripting languages, but there I'm talking about me. I don't believe everyone should use tools the way I do. Nevertheless, I do recommend to systems language enthusiasts that they also learn a scripting language well enough to use regularly. I have found that knowing a scripting language makes me much more productive for the "short hikes."

> What scripting language would be a good one for a Java
> programmer to start on? The three I hear mentioned most
> these days are Perl, Python, and Ruby... I've dabbled a
> bit in all three but not enough to get a strong grasp on
> what the day-to-day advantages are between one and the
> next. It does seem to me that Python and Ruby are more
> readable than Perl, and Ruby professes to be more purely
> object oriented than Python.
>
> However, from a Java programmer's point of view who only
> is interested in taking "short hikes" with these
> languages, it seems like the main goal should be speed of
> development and not necessarily OO purity or readability.
> And Perl's ubiquity on Unix systems is hard to ignore.
> However, I also heard that Perl 6 will be a ground-up
> p overhaul of the language...?

For a Java programmer, I'd say the hands-down choice is Python:
- Ruby's old claim that it is "more OO" is no longer the case anyway.
- Perl is infamously cryptic and Ruby has quirky syntax (looks like BASIC without the BEGIN keyword).
- Jython. This Python/Java synthesis allows you to use Java classes in Python, among other things. (maybe there is something similar for Perl or Ruby?)
- Python has a ton of useful libraries (in fact, one of Ruby's saving graces is the fact that it can use Python libraries).
- I found that Python was very easy to learn and that it does most things in a way that are brilliantly simple.

An interesting addendum to the "strong versus weak typing" discussion:

One example of an error case that Python uncovered for us was caused by an external prediction program that would usually return a numerical error code but in some cases was found to return the string "error" instead. In Perl, strings and numbers are converted automatically, for example the string "123" becomes the integer 123. Unfortunately, Perl also converts non-numerical strings, such as "error", to 0. As a result of this, Drone was treating "error" as a successful return value, leading to incorrect results. Python's stronger typing uncovered the error as soon as the rare case that caused it was executed.

From "AstraZeneca Uses Python for Collaborative Drug Discovery" at http://pythonology.com/success&story=astra

This helps to illustrate the contrast between weak typing and dynamic typing.

The problem with this argument is that the refactoring tools
that started the current trend were written in and for a
dynamically typed language: Smalltalk.

It is perfectly possible to create similar tools for Python.
One example under construction can be found at http://sourceforge.net/projects/bicyclerepair.

What scripting language would be a good one for a Java programmer to start on?

I would recommend Python to a Java programmer for two reasons:

1. The Jython implementation. This is Python written in Java. It can subclass and be subclassed by Java and is compatible with the main Python implementation ("CPython") at the language level. The C implementation does have a lot more standard library modules.

2. While Python programs can easily be purely object oriented, they don't have to me. This is useful to jobs where an object oriented solution is not an advantage.

For the quickest overview of the debate, check out page one of the Strong versus Weak Typing installment of the Guido van Rossum interview:

I think that the weakest part of that interview section is that neither of you mentioned real contracts (as in Eiffel). While I agree that the "contract enforcement" benefits of strong typing are generally overstated, the I suspect that the benefits of real Design by Contract support are substantially greater.