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

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.

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 find many programmers don't understand the relationship between their code and the systems their code rides. They overdo it, driving up costs and the time of delivery for the sake of bullet proofing.

The reality is the correct tool for the job not only encompasses the choice of language, but also the hardware and network environment the resultant application will reside. They must complement each other for the task at hand.

For example, lets say we have an internal application that at most 50 people will use in your organization. Response times are not critical (we are not building the space shuttle here). Now given that the worse case senario is 50 connections, and more likely an average of about 5 or 6 connections at any given point in time, what would be the correct solution? Many times this ends up being a java or C++ application running on a fully redundant mirrored environment (perhaps MC Service Guard environment on a high end HP). In reality, the application could be emplemented on a Sun Blade/Ultra single processor box with an automated backup routine using readily available Zope and Python. It would be implemented quicker, the users would be able to give more immediate feedback, changes would be trivial, and the developer would really serve the users what they need when they need it.

The problem is we think in terms of gold plating and bullet proofing our applications in various ways - at both ends of the spectrum. Not only do we use the most 'stable' and/or 'efficient' language implementation, we then further elimenate all possible exposure by over engineering the hardware solution. I think some of this stems from the overspecialization of programmers. I often question the motivations of anyone who refuses to learn new languages, and other aspects of system development outside of their area of expertise.

Every project is not the space shuttle - in fact, <i>most</i> are not. Outside of mission critical code (such as nuclear reactor code, or code that controls the space shuttle engines), imperfect working code in the hands of users now beats perfect code 14 months from now.

(To toot my own horn, I have built programs using the following languages: basic, fortran, C, C++, Java, Perl, Python, sed, awk, sh, csh, tcl/tk/expect, x86 assembler, sparc assembler, and lisp)

Quote from article:
"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."

My reply :
I think ability to code plays a part in whether to use another language and or script instead of the language the developer is skilled with. Still learning another language can be of great value.

Here are some thoughts (abstact or not) towards this view and in practical terms. Please consider.

1): retention of language semantics and its usage.

An efficient programmer with one specific language should be able to do about anything whether strongly typed or not.

Why? There is an ease of use reference within the mind which the coder develops as the continue to use the language. Like lifting weights at first, your muscles find it difficult and you tire easily. Later ease of use and enhanced efficiency develop that you become more intense
with lifting heavier weights (if desired) and your speed in lifting improves as well. So why consider another language.?


2): Use a script language:

The coder could create his own simple script language for specific duties they might have in mind. If setting the languages real code to the text editor is difficult, I agree it may be at times especially when your at the top end of your performance threshold and it is the end of the day or the middle of the week. It is good to use another language as a distraction while the formulation of code references set up in the brain. Again , it may be just as well to create your own script.

3): Change attitude towards existing language the coder may be enriched by it.

How about applying a changed attitude towards the way you code when using the same language. Since the tasks your thinking about are less important and could be done with the language your using but at the time your language is too difficult to work with then enhance your skillset by starting to or create a library (if there is time) to objectify the specific tasks code.

Keep adding to your library of less importance. You then are creating a new level of expertise which will enrich the
flavour of your ability.

As well you may develop a more diversified perspective on how to code. Like a window refresh if you will of your own disposition. cleaner , crisper - leaner - meaner.

It is an intersting topic with many appropriate answers and I have wished to and have learned other languages too. I found in my specific instance (of being human) that selecting another language was because I was too tired to make the language I was seemingly skilled to work with work the way I wanted it too. It is interesting that I got over it.


Thanks for reading

David W. Stubbs