The term "scripting language" is so ill-defined as to be rather useless as a focus for discussion.

To me, the opposite of a scripting language is one in which each change to a program requires a lengthy build process, and the usual indication of a bug is a coredump or a (slow or fast) runaway memory hog. The speed of the edit/test cycle and the elimination of many classes of bugs common in C code are big plusses for scripting languages in general, and perl in particular.

There are a variety of languages that offer this "scripting" benefit; maybe some of those are not suited to building large applications, but I suspect in most cases all they need are the right methodology - certainly, after I had spent only a year or two working with perl it is unlikely I could have designed something the size of my current work project with any success, but I've experimented with enthusiasm, and now I'm perfectly comfortable tackling large projects.

Next time you are on Andrea's sofa, maybe you should try asking the guy what "scripting language" means to him, and then exploring his individual points in relation to perl.

Hugo

Next time you are on Andrea's sofa, maybe you should try asking the guy what "scripting language" means to him, and then exploring his individual points in relation to perl.

Part of the problem is that this technique doesn't work with PHBs. Many more companies could profitably use Perl and take advantage of the fact that it doesn't have many artificial limits on what programmers can do. Further, when I think about trying to reach the masses with the "stop using Perl 4" argument, I can't have a dialogue with each and every reader. As a result, I need to think of "marketing" points which can get these issues across succinctly.

Cheers,
Ovid

New address of my CGI Course.

This technique can be adapted to suit addresses to PHBs and anonymous audiences, though.

For instance, if/when a PHB says "But Perl is just a scripting language!" you might affect a confused look and say "How do you figure?" Put the opposition on the defensive, because you know he's wrong, and it will be easy to shut down the opposing argument as soon as you know what that argument is. If you try to offer a counter-argument without finding out what it is, you'll fail to make a strong impression. If the PHB knows something, he'll give you an argument to which you can respond substantively. If not, he'll give you a broken "I heard it on NPR" type of pseudo-argument excuse that can be diplomatically defused by responding to the specific concern that was raised — possibly by saying "Oh, that hasn't been true since Perl 4, a decade ago. The problem isn't the language, but the fact that a lot of people are still writing Perl 4 to be executed by their Perl 5 interpreters."

In the case of writing for an anonymous audience (such as writing an essay at PerlMonks, an article for a magazine, or an introduction for a book about Perl), there's a very common and rhetorical technique employed every day to which this applies: one first explains the case for common approaches to the opposing argument (saying "Many think of Perl as a scripting language because . . ."), then one debunks them all in the text of the essay (or whatever). In other words, make your opponents' arguments for them, then dismantle those arguments with "new" arguments of your own. The answer to some of these, as well, will be "That's Perl 4, not Perl 5. Here's why."

It doesn't immediately educate the whole world, of course, but it's useful — and nothing else we can do will immediately educate the whole world, either. Even Sun's message that Java should be used for everything took some time to propagate.

print substr("Just another Perl hacker", 0, -2);

- apotheon CopyWrite Chad Perrin

I have occasionally been irritated by the condescending way Perl is referred to as 'just a scripting language', and I agree that it is a poorly defined term.

The Wikipedia article acknowledges the ambiguity of the term, but helps to identify why it is used in a disparaging way:

• Scripting languages are associated historically with batch programs and job control language (JCL). As such, they are not 'true' programs, but 'mere' shells or shoehorns by which the actual programs are run. To the extent that Perl is considered the equivalent of mainframe JCL, Perl can be contemptuously dismissed, at least by those with minimal exposure.
• The emphasis in the popular perception of scripting languages seems to be on the assembly of existing components, rather than the development of new components. The existence of the CPAN contributes somewhat to this view -- a skilled Perl developer can often assemble complex applications with considerable reliance on other's code. While this is a huge advantage from a developer's perspective, I think it has contributed to the way in which Perl developers are sometimes sneeringly described as 'assemblers' rather than 'developers'.

No good deed goes unpunished. -- (attributed to) Oscar Wilde

My reply was extensive enough that I made an update to the root node of this post. I don't think anyone should mistake my main point, but it's clear from what you wrote that I failed to make the point clearly enough.

Cheers,
Ovid

New address of my CGI Course.

Maybe it was just me who failed to grasp your main point :)

At any rate, I think my point is still valid. The distinction to me is that instead of saying "you're out of date, Perl *isn't* a scripting language", I think the actual message should be "you're out of date, Perl's not just a scripting language, it's so much more!" (wow, that *really* does sound like marketing :)

The rest of my tirade was just my thoughts on how we got into this perceptual mess in the first place.

Never having used Perl 4, I'd be really interested to see half a dozen or so examples of P4 -v- P5 code to demonstrate your point. I've acquired a passing awareness of some of the differences through osmosis. Eg. Hashes and arrays couldn't be nested? Though why not escapes me, when the both contain scalars and refs are scalars. Unless there were no refs in P4?

I guess my point is that for the old hands who did several years of P4 before the last 10 (?) of P5, your "Stop writing P4" argument may be enough, but for all those (like me, and maybe 30%, 40%, 50% (more?) of current users), that only came on board since P5, it alludes to something that seems like it probably makes sense, but without examples of what we are doing to offend you, the allusion is only fleeting. It lives in "Yeah! Right on! Like, you mean like... um... er"-land

You can read some of the differences in this old perlfaq.

Just imagine trying to build a scalable system without lexical variables! When I did that in COBOL, we had horrible variable names like WS-GLJ0030R-ACCT-LIMIT to avoid collisions. Real fun! Oh, and in Perl 4, you had true globals by forcing variables whose names began with underscores into main::. This is often a convenience and you can see remants of this with variables like $_, $1, and so on. However, for programming larger systems, encouraging user-supplied globals is bad.

Cheers,
Ovid

New address of my CGI Course.

So as someone else who started, many years ago, with Perl 5 ... I'd have to say, doesn't this take away from your argument? I've seen my share of "not great" perl, and most of it still used lexically scoped vars (AIUI Perl 4 used typeglobs a lot more too ... but that's also something I don't see).

If anyone said "oh, isn't that just a scripting language" to me recently, I'd be tempted to reply "What, like Java?"

--
James Antill

For historical interest the examples from the first edition of "Programming Perl" can still be found here. There were no references, lexical variables or "use" for starters. But I think you'll get the flavour from the examples.

/J\

You can also look at this Excellent Perl 4 Resource >:-D

#!/bin/bash is not my preferred way to start building large scale tools, but I've heard about people building Web sites that way (well, back in the 90s).

Cheers,
Ovid

New address of my CGI Course.

Thanks, I thought I'd repressed all memory of an ancient version of the Remedy "web interface" but this remark brought it all back. A whole bunch of little CGI shell scripts which all sourced one mongo common file which defined shell functions to implement all the different behaviors (all of which had to be parsed for every single invocation).

(Rewrote most of it in Perl and it went from 5+ seconds to generate a page to ~2 seconds; moved to Apache::Registry under mod_perl and got that down to actually useable).

*shudder*

I take it we're all familiar with the dd/sh language, from the same warped genius as perlfs?

having just completed a stint updating a website -- very elaborate -- built in ksh in that time period, I just say "one page at a time..." :D

Don Wilde
"There's more than one level to any answer."

So when people tell me that Perl is just a scripting language, I think I'm going to reply "you're talking about Perl 4, something that stop being maintained over a decade ago. Tell your programmers to stop writing Perl 4."

That's not a bad response. I tend to prefer "so the hell what?"

The only thing that really matters to management is "can it do the job?" When a PHB objects to a plan on the basis of "Perl is a scripting language", the best response in my experience is "Perl can do the job just as well as {alternative}, but I can get us there faster and cheaper with Perl". If you make that argument (and are prepared to back it up), any marginally competent manager will drop the whole "scripting language" angle.

In short, the best way to handle this objection to Perl is to point out that the distinction between "scripting language" and "programming language" is incredibly unimportant. What matters is what you can do with it.

The only thing that really matters to management is "can it do the job?"

Ahh, if only this were true. So much management also cares about it being Windows compatible or if it's Sun's new gimmick or if IBM is going to segue the iSeries into using it or whatever. There's a lot more silliness that goes on.

As a Mac guy, I love to talk about objective-c, which is a beautiful language. The way I've read it in the past has said (roughly) that first there was C, and then people decided, "Hey, this object oriented stuff is pretty cool! Let's make C object oriented!"

And two things came out of it initially. C++ was C with simula style objects grafted onto it, and was designed to produce fast programs. Objective-C was C with smalltalk style objects grafted onto it, and was designed to produce fast programmers. It's an important distinction.

The rationale was that computers are cheap and people (especially good people) are expensive. It's cheaper to put beefier hardware onto your app that you deployed in 6 months that it would be to use cheaper hardware and deploy in 18 months.

I tend to tell people this story and add on that I really like Objective-C, because it's almost as fast as C and almost as flexible as perl. I can develop very fast in objective-c, but I can do it even faster in perl.

And at the end of the day, that is all that really should matter. Scripting or compiled or byte code or whatever - who cares? Make the programmers faster and everything else works out. Perl's real good at that.

There's also the simple fact that management tends to think in terms of what "customers" (whatever they may be in this case) are going to say. "Wait — you're trying to sell us an application written in a scripting language?!" PHBs feel like their credibility is shot if you use a language that's not buzzword-compliant enough.

PS: ObjC rocks my socks, and it's not just for Macs anymore (well, it wasn't originally either, but that line sounds good).

print substr("Just another Perl hacker", 0, -2);

- apotheon CopyWrite Chad Perrin

My take on whether Perl (or any other language) is a scripting language is largely derived from a Larry Wall quote, actually (though I reserve the right to change my mind tomorrow). He said "A script is what you give the actors. A program is what you give the audience."

This says something somewhat profound about the difference, though his meaning may not have been the same as what I'm seeing from my own perspective. Scripts, it seems to me, are for programmers, while programs are for users. This means that software written primarily for the benefit of programmers is more a "script", and software written primarily for the benefit of an end user is more a "program". Persistent compiled executable binaries are a more program-oriented feature, while executed plaintext files are a more script-oriented feature. Large, comprehensive GUI applications that include at least some interpretation of a kitchen sink are more program-oriented, while small, "does one job and does it well" utilities that can be chained together to produce more complex behavior are more script-oriented. A set of utilities that are well chained together in that manner might be a program, however. Something easily read, the entire concept of which can be held in one's head at once, is more script-like, while something whose design "under the hood" can only be understood and held in one's head in chunks is more program-like. Et cetera.

Frankly, I'm inclined more toward things that might be called "scripts" according to the above checklist, anyway. I like being able to see source code. I like functionality that can be executed separately from other functionality as atomic little utilities, as opposed to massive captive interface programs that must be started almost as a virtual machine OS within your OS to be able to access a single feature such as a word count button. I prefer glue code over tight coupling. I like software that can be run without starting a GUI. That doesn't suit the common proprietary closed-source software development and marketing model, though, because it's difficult to sell simple, elegant software as unique products — it's too easy to replicate the individual utilities' behaviors, at least partially. As long as corporations continue to want to sell monolithic, "feature rich" applications and leverage legislation to prevent copying and sharing, rather than generating revenue for things that actually are singular, unique, and difficult to reproduce cheaply (in time as well as money) like comprehensive support and customization of complex systems, we'll have to deal with the question of "scripting" vs. "programming", with "programming" being the automatic winner in the minds of many. C'est la vie.

So, at least in my case, the phrase "Perl's a scripting language" was just a step in the evolution ladder.

BTW I think there's plenty of people who come similar way...

BR,
Vadim.

PS. my English sorrey unperfect

"To become popular, a programming language has to be the scripting language of a popular system. Fortran and Cobol were the scripting languages of early IBM mainframes. C was the scripting language of Unix, and so, later, was Perl. Tcl is the scripting language of Tk. Java and Javascript are intended to be the scripting languages of web browsers." ( Paul Graham ).

The one that stuck in my head was C being the scripting language of Unix.
In this context, Perl as a scripting language does not sound that pejorative.

perl -MLWP::Simple -e'print$_[rand(split(q.%%\n.,
get(q=http://cpan.org/misc/japh=)))]'
[download]

Signals have since been fixed to be safe.

More precisely we now have a choice. Working unsafe signals, or not working safe signals.

What I mean by this is that we can either choose to allow signals to interrupt long atomic calls (eg an attempt to connect to a database with DBI) but suffer potential core dumps, or else we can choose safety but not be able to use alarms to get timeouts to work.

As far as developer productivity and implementation flexibility goes, scripting languages such as Perl, will always provide a more efficient and productive way to get things done. The development of large and complex systems in Perl, or any language for that matter will only be successful if the supporting processes (coding standards, style guides, development methodolgy, etc) are enforced and followed. Software maintainability, for scripting/interpreted languages will always be an issue if this isn't the case.

While I might be biased towards Perl :-), I've used it to build extremely large and complex systems, and (I guess this is where Perl shines the most) for ad-hoc development, prototyping, sysadmin stuff.

Perl is not going anywhere, or dying anytime soon. The 'sloppy' use of Perl for large applications should have died 10 years ago, but hey, I guess that's the price you pay for flexibility. Not to mention the benefits of productivity, mountains of CPAN modules, and an extremely large and competent community.

As a side note, I also get a little upset when people complain about potential performance issues of Perl. In a commercial environment, developer productivity is a big selling point (especially to management). In practice (depending on the application of course :-), you'll find that most of the time, Perl is more than sufficient as far as performance goes. If you need some platform dependant functionality, or better performance, write that bit in C and get on with the important things :)

Perl is written in C, so when the parser has figured out what you want to do, you're executing compiled code as fast as any C program.

Excellent. Now I know that every language, like PHP, Ruby, Prolog, Javascript, etc. is as fast as C.

A script is a bit of code which is developed quickly to provide functionality which may have dynamic or frequently changing requirements. Aprogram is developed more slowly but runs quickly; the program satisfies requirements which change little or only slowly.

Fifteen years ago I wrote a script using a series of shell commands to determine how much space each user was occupying in the file system. Today I use Perl to process 500,000,000 records a day into Informix databases .... am I dealing with scripts or programs? After all, 30 years ago any computer, any language would have been challenged to keep up.

I wouldn't use Perl 5 to implement an operating system, I wouldn't advise using it to run a nucear power plant or an airplane or a rocket ship ( but some perverts are using MS OSes for that! ). On the other hand, just because someone is writing code in C doesn't mean their prgrams are important or good. ity just means it will take them a week to write something I can have ready in a day.

script languages are compiled on the fly. you can program in scripting languages, but you must include the compilation time of the script + the loading of the interpreter to be significant. thus you have mod_perl and fastcgi. the compilation is cached but as an addon facility. php has something or the other like that.

java is kinda in that land, where the jvm loading is the only significant part.

where as c has no vm beyond the kernel and it's os facilities.

I'd say something like "why not? it's Turing complete - why would it be less suitable for writing systems in because it employs just in time compilation instead of static compilation?".

Especially if theis person is a C programmer he's not going to have any arguments about the potential for obfuscation ;)

You can also defuse the situation by offering to increase the stakes, and letting the other party back down. "Let's both solve the same programming problem, and see who gets done faster. Would $500 be an interesting wager? Of course, I might use a different language if I think it would be better for the task at hand, but I win most of my competitions with Perl."

This approach does leave an impression. Make it clear that CPAN is part of Perl, and don't challenge anyone who knows Haskell.

It should work perfectly the first time! - toma

:) Your comment reminds me of the comment by David Heinemeier Hansson (the creator of Rails) who once posed a similar challenge at during a conference presentation, with a similar caveat. It went something like

I challenge anyone to build an interactive web app faster than I can build it in Rails. Anyone except Avi.

Avi being Avi Bryant, author of Seaside - the insanely cool Smalltalk web framework.

In the end, it only depends from which side of the 11-sided coin you look at the world from.