The State of the Scripting Universe

r.jimenezz writes "Via PragDave's blog I learned of an article by Lynn Greiner on the state of scripting languages, a.k.a. scripting dynamic languages. A number of influential personalities (Guido von Rossum, Damien Conway, PragDave himself and others) were interviewed and it's interesting to see how much their opinions coincide despite being interviewed separately. A lengthy but worthwhile reading."

Comments

What defines a scripting language?

[tchuladdiass]

I have often wondered what makes a particular language a "scripting" language v.s. a "real" language. One thing scripting languages all have in common is that they are interpreted. However Basic is interpreted (even though some may dissagree that it is a "real" language), and there have been interpreted versions of Pascal and others.
The best I can come up with is that a scripting language is an interpreted language that is normally attached to an application in order to allow the end user to automate functions within that app. So for example BASH programming is "scripting" since most of what you do is items that would normally be done at the command line. Same with Word/Excel macros. Also, TCL was designed to be attached to other programs (although the typical use is stand-alone). But I wouldn't put PERL in that catagory, anymore than GW-Basic or interpreted Pascal are scripting languages.
So, what does a language need to be called a "real" language, other than being compiled?

I hate dynamic languages

[Anm]

I've said it before, and I'll say it again.. I hate dynamically typed languages. Just to clarify, this isn't about interpretted versus compiled languages. In fact I love high-level interrupted languages, with syntactic sugar to make my life easier and the ability to edit code during execution. But dynamically typed languages have a serious problem.

Lets say you have to added a feature to the following function:

updateCustomerAccount( customer, newInfo )

Looks nice, with very descriptive function name and parameters. But it isn't. Is customer a string name, a an accountId, or a data structure? Does it return anything (success or failure code)? And a little more debatable, does it throw any errors.

The usual cases are:

• You wrote it. Great for when you've just been working on it, but not so great if you're coming back to it after a while or are juggling multiple similar projects.
• Read the docs. Unfortunately, docs and code regularly get out of sync unless every single member of your team is very tedious to such details. This is especially true of internal APIs. Besides, if you now require such tedious attention to detail at every check in (as opposed to public release where your API docs better be correct), haven't you lost most of the supposed benefits of the script/high level language?
• Ask the author. Brings programmer out of the code, and not very useful when its more than just down the hall. For distributed development like OSS, email is a slow solution.
• Use the source. Again, brings the programmer out of their current objective, and this can often be tedious and error prone. That said, there is always a case where this is necessary/useful/insightful.

But even if you can always rely on one of these solutions, you're missing out on the beauty of statically typed languages: IDEs. By formally typing objects in the language grammar, you have not just documented your code to your peers, but to the machine itself. And allowing the machine to reason about your code means it can help you write it. It keeps you in the code, with instant access to API, documentation, and refactoring. Now you have mentally stepped beyond the code into the problem space.

Anyone who has written Java in a solid IDE like Eclipse can atest to this. I've had I've had people look over my shoulder in amazement as "the computer writes [my] code" for me. Every function appropriate to the context (and their documentation) usually within 6 keystrokes, without memorization.

Even the best Python IDEs (strongly typed, but still dynamically typed) pale in comparison to this experience.

When will the scripting world learn what they're missing?

Anm

(For the record, my prefered langauge is Java, but my current work has me doing C, C++, Python, and Perl as necessary. While I haven't worked in it, I assume C# is in the same boat as Java: statically typed, runtime reflexective, dynamically loadable, useful exceptions/stack traces, and large library including the source compiler itself.)

Re:I hate dynamic languages

[Bastian]

I agree that this is a serious problem with many dynamically typed languages, but, if I may use the cliche, don't throw the baby out with the bathwater. There are two good solutions to that problem that I can see.

The first is commenting. (If you can't keep your comments in sync with your code, you have a much bigger problem that you should work out before you even start to argue language paradigms.)

As for the second, there is nothing in the definition of a dynamically typed language that says you can't include types for function parameters. Personally, I would love to see a dynamcially typed language whose syntax allows for it. In the end, it would just be so much syntactic sugar - a dynamically typed language would just convert the value you pass to the function if it doesn't match the type. However, it would force a higher minimum for readability in code, and it would provide a mechanism for having a -Wall style compiler option for giving warnings about type mismatches. (And before anybody complains, yes, there would be a generic type for functions and data structures that you really do want to be able to handle everything.)

Really, I think the whole reason why this hasn't happened in any popular scripting languages is becuase the popular scripting languages are designed for very small projects, where you really don't get that much benefit from such a feature. Plus, in my experience, programs written in dynamically typed languages do tend to be better commented. It's a lot harder to escape when you're dealing with a class of languages that tends to be rather on the terse side of things.

Re:I hate dynamic languages

[cratermoon]

• Use the source. Again, brings the programmer out of their current objective, and this can often be tedious and error prone. That said, there is always a case where this is necessary/useful/insightful.

If reading source code takes you out of your current objective, you have a write-only view of programming, and that's a problem. Take a look at http://www.spinellis.gr/codereading/

Re:I hate dynamic languages

[Bastian]

First, the problem isn't limited to function parameters. It's just the example I used. I think the issues are equally present in typing class/struct members and collection values.

I'll follow your new example. Why don't we allow for casting suggestions on struct or class members as well? We can take this as far as we want. I it's just documentation sugar and a debugging aid.

Secondly... you want to make programmers go through the effort of naming their types, but you're not going to enforce them? So despite the extra effort, the system may still allow different types, thus the typing only describes the intent?

I've already explained this. . . it wouldn't be strictly enforced, but you could have the compiler do checking for you and issue warnings. It's really not that much different from the warnings that you get with, say, C, where you can cram anything you want into anything else, and the compiler will figure out some way to munge the data so it compiles cleanly. As for calling it extra effort, let me suggest that a) it isn't any more effort than goes into figuring out what types data should be in a static language, and b) even if it's ignored, forcing programmers to put some modicum of explanation in with their code is a Good Thing. Call me insane, but I've always been of the opinion that minimizing bug count is generally more important than patronizing slothful programmers.

And you are still left with the possibility of strange runtime errors. . .
Please be more specific. Every language I have ever written code in, from FORTH to LISP to C to Java, has given me problems with strange runtime errors.
. . .and possibly misspellings that type checking would catch.
Not all dynamically typed languages let you get away with not delcaring your variables. I agree, variable declarations are a Good Thing.

These type of in place corrections (i.e., don't make me go edit the other file manually) give me the speed a dynamic language coders without loosing the safety of my static typing.

I fail to see why this is a feature that is only possible for an IDE that works with statically-typed languages. Data type never came up in that example, though you did refer to a class as a type. I'd only be willing to let you get away with that if your answer were using a language like Smalltalk where class and type are pretty much the same thing. =D

Re:I hate dynamic languages

[p3d0]

If the information you're missing by omitting type annotations matters to you, then don't use a dynamic language. However, dynamic languages are good for prototypes, and for simple systems. They scale downward further than statically-typed languages. I use them for fun hobby programming, but (for the reasons you mentioned) I don't use them much for professional work.

I'll give you a pathological example. Consider the Hello World program written in bash (a dynamic language) and Java (a static one). Java looks like this:

public class Hello {
public static void main(String[] args){ System.out.println("Hello, world"); }
}

Bash looks like this:

echo Hello, world

This isn't really a fair comparison per se, but hopefully it illustrates my point regarding the complexity of the problem versus the effort required to code the solution. On the one extreme, you have the "static" languages designed for coding entire "systems programming products" (to borrow a term from Fred Brooks). Of these, the good ones (eg. Eiffel, with its superb multiple inheritance facilities) scale up well to large systems, so the asymptotic slope of the complexity-effort curve is small. However, that curve doesn't cross the origin; that is, as the problem becomes trivially simple, the code required to express the solution reaches some fixed minimum size. In the case of Java, for instance, every program must declare a class with one public static void method taking an array of strings as an argument. That's why nobody uses Java as a command shell.

On the other extreme, you have shell languages. They do indeed intersect the origin of the complexity-effort curve: that is, it is possible to write a two-character program that does something very simple, such as "cd" or "fg" in bash. If you allow aliases, or UNIX commands like "w", you can write meaningful one-character programs. (This is impossible in Java, no matter what definitions or libraries you presuppose.) However, the slope of the complexity-effort curve is high, and after a program gets larger than a few hundred lines of code, bash becomes almost unusably awkward.

In between, you have "dynamic" languages like Python. Its curve doesn't hit the origin, and its asymptote's slope is higher than Java's, but there is a sizeable range of programs for which a Python solution requires less effort (at least for me) than bash or Java.

So, as many others have said, it pays to have a number of tools in your toolchest.

Re:I hate dynamic languages

[Anonymous Coward]

Common Lisp is dynamically typed, but with optionally enforceable type annotations and static-style type inferencing in good compilers.

Re:I hate dynamic languages

[Pedersen]

In the case of Java, for instance, every program must declare a class with one public static void method taking an array of strings as an argument. That's why nobody uses Java as a command shell.

What's the problem with that?.

The problem with that is for extremely simple programs. And by extremely simple, I'm talking about stuff that barely even qualifies as a program, but would be tiresome to type over and over again. Consider, for example, the case of the classic "Hello, World" program, that the GP gave.

In sh, it's one line, literally. There's no command line parameters, nothing. Just print something out. In Java, you must have three lines in a file, and then you must compile that three line program. All for something meant to display something on the screen that the user is not meant to change.

So, what's the problem with all of that? Sometimes, you really do want to have just a short script, simple, doing the same few commands regularly. Java (or other compiled languages) add a layer of overhead which is completely not necessary for such items.

If you allow aliases, or UNIX commands like "w", you can write meaningful one-character programs. (This is impossible in Java, no matter what definitions or libraries you presuppose.)

Wrong. Aliases has nothing to do with a language. You can alias w=java -jar myapp.jar or whatever command line you want, or write a shell script to do the same, which is the usual way to start a Java program.

Actually, you've missed the point he was trying to make: It is possible to write shell scripts which do something genuinely useful with only a very few characters. This is, unfortunately, not possible with a full compiled language, such as java, or c, or c++, etc.

Re:I hate dynamic languages

[platos_beard]

Not too long ago I would have been in complete agreement with you, but recently I've been dabbling extensively (I know that's probably an oxymoron) in Python and I'm not so sure any more. Take the code:

bar = map( lambda x: x[1], foo )

Maybe it's possible to do that with static typing, but if so it would add so much grief in making sure all the type related stuff fits together as to be barely worth doing. And it is worth doing.

So I'm moving toward the conclusion that dynamic typing in and of itself is a plus. Not just for prototypes, but for real power and conciseness.

Re:Code Insight

[Anonymous Coward]

This is not hard a characteristic of dynamic vs. static typing. There are languages such as Common Lisp where one can _optionally_ declare types, and methods specialise on class, not type, anyway, so even without any type declarations, an OO program in CL allows such hinting.

i take exception with this

[portscan]

When do you use a hand saw, compared to using a power saw? Different carpenters will have different answers. But having both at your command makes you a better craftsperson.

perhaps it makes you a more capable craftsperson, but just having the tools does not really help. better? maybe, but not necessarily good. it's knowing when to use one over the other that really makes you good.

that being said, i love perl for quick stuff, i/o and text processing, and lots of other things. php is great for web and i am definitely interested in looking into python...