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

Dun dun dun...

[ciroknight]

The research firm reports that over 41 percent of the 666 developers surveyed use Perl, 32 percent use PHP, and 15.6 percent use Python

The Number of the Devil of Programmers.. looks like it's as I always said, scripting languages are evil..

You dont use a sledge hammer to open your penuts

[FidelCatsro]

Scripting languages will always have a place , Its a simple case of the right tool for the job.
As a sysadmin most of my Programming is done in either ruby(im difrent) , shell(bash or ksh) or perl. Using C for most of the things i have to automate is as i said "Taking a sledge hammer to a penut" , It would be total overkill and waste my time and the systems and it would be more error prone .If i do have a larger project that requires a bit more power then i can prototype it in perl or shell then easily transcribe it to C .
Scripting will always be an important part of my work , and with the increasing power and decresing price of computer equipment over the last few years , it has become viable to program many many things in languages such as python , things which would not so long ago, would have requierd the power of C/++.
Scripting is in a fine state , and will continue to fill its end of the market , just as compiled languages will always have their place

Another cool article about Tcl

[DavidNWelton]

This article:

http://www.devsource.com/article2/0,1759,1778148,0 0.asp

talks about some of the cool stuff that Tcl does. My favorite thing about the language is that it hits a real sweet spot with its level of abstraction. Python has an event loop now, in Twisted, but Tcl's had the same thing for ages, and it's very easy to use.

Developer productivity vs. CPU productivity

[G4from128k]

For projects below a certain complexity level, I've always found scripting languages to be more productive for the programmer (very fast edit-run-debug cycles) even if they are less efficient for the CPU. And with the advent of JIT compilers, the efficiency of scripting is much improved.

Given the low-cost of fast CPUs and high-cost of programmers, I'd rather waste CPU cycles than waste developer labor.

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

[chris_mahan]

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

Ah. is customer an object? is the new info an object?

is it smart-merging "newInfo" to "customer"?

I can come up with a bunch of things that might affect how one uses this function that would not be infomationalized by the addition of types:

is it accessing an outside system, such as a database?

is it asynch?

Does it assume security of the user? In the Customer update log, what is the name of the person who entered the newInfo?

Is the newInfo an xml document with inbedded base64 pdf? (i've seen in, in mortgage systems)

Does it notify a third-party in case of failure, logging to the logger, and returning a "pending verification" semi-error code?

Does it allow for customer to be empty, and if so, does it create a new customer?

Does it allow either to be empty, thereby creating a new customer with blank, or default information?

if the newInfo contains a dataset with as-yet unknown fields, is the system desinged to automatically add the fields as xml tags in the customer xml storage?

Is the previous information in the customer file store elsewhere? as in a change log?

All functions need a solid API. Since you're going to have an API, you might as well put the type handling in it.

If a programmer can't be bothered to keep the API docs updated, he is not staying on my team.

To some questions, the answer is Python.

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

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

The ideal language (processing methodology)

[garyebickford]

IMHO, all languages should be 'scripted' as well as 'compiled'. The same language syntax can be both. Why not use our advanced computational tools to do the grunt work of optimizing functionality? We've automated every other engineering discipline, but can't seem to do that for our own. (I know I'm overstating the argument, handwaving and idealizing - it's a dirty job, but somebody's gotta do it.)

What I'd like to see: As I enter code in the language, the system does syntax checking and builds the necessary data structures, prompting and possible asking questions about ambiguities and any necessary library functions either not found or not called correctly. In fact, this process might as well be graphical in nature - NeXTstep's Interface Builder perhaps came closest to this in my experience. The code should be runnable immediately, in an interpreted environment - a la Perl/Python/PHP etc.

Thus language processing system would act as an intelligent assistant, looking over the system as I design and build it and making suggestions. It might even make performance predictions based on its analysis of the code-so-far.

Once the functionality is complete, I can pass the system to an even smarter optimizing compiler function, which does the necessary things to make it efficient, small, fast, etc. In the process the compiler may ask more questions about how to resolve various issues that didn't come up earlier. Since the functionality is already defined, the compilation has a mostly-known target for functionality. This process can take as long as necessary, perhaps while I go home for dinner; using more heuristics, AI, whatever, to further improve and clean up the system for the defined functionality.

Except for the AI features, this combined capability is actually old. Back in the Long Ago, Harris computers ran the Vulcan OS, which had a n interactive FORTRAN system. It did line-by-line compiling, doing syntax checking on each line and even running the code. Once your program was complete and ran, the interactive compiler could output correctly-formatted FORTRAN that could be compiled using the standard FORTRAN compiler.