So I was sitting on my friend Andrea's sofa, talking to one of her other friends, a gentleman who also happened to be a programmer. Turns out he built systems in C. When he asked about what I did, I told him I built systems in Perl. He was confused. "The scripting language?" I replied that a lot of people think that, but it's not true and I build large systems in Perl, far larger than most people think. And his response? "Yeah, but Perl's a scripting language." He was very confused and when the conversation was over, I think he thought I was either lying or just very naïve. Maybe the latter's true, who knows?
You can debate all you want about what a scripting language is or isn't. I'll smile happily and start daydreaming because this discussion is even less useful than strong typing discussions. Instead, I started thinking about PHP. PHP 5 has been out for about 2 years but the majority of PHP code is still PHP 4. What's worse, given my experiences with Perl, I suspect that a lot of PHP 5 code is still being written to look like PHP 4. However, for those not familiar with PHP, I doubt they could even tell you what version it is. I doubt they could tell you what version Ruby or Python are up to.
Why is this relevant? Well, what do I think a scripting language is? Despite my earlier assertion that I'm not really going to pay attention to any debates on the topic (because truth be told, they bore me to hell), the fact is that I still have a mental model of what a scripting language is. That's a language which is suitable for writing smaller "glue" bits of code, but not larger systems. Admittedly this is subjective, but a scripting language is to a "real" language as erotica is to pornography: I know it when I see it (further research is needed in this area).
This was an awfully circuituous way of getting around to my main point. By my personal, highly subjective and faith-based view of what a scripting language is, I would suggest that Perl 4 qualifies. In fact, there's still so much Perl 5 code being written in a Perl 4 style that this code is pretty much indistinguishable from a scripting language. I think many MySQL developers should be sympathetic because there's still a lot of crap being written for MySQL 5, despite the fact that it's becoming a serious database. 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."
Update: Mutant's response made it abundently clear to me that I haven't gotten my main point across, but since I never used the word "marketing", that's not surprising.
I understand Mutant's point, but I'm looking at this from a marketing viewpoint (yeah, yell at me later). Instead of letting the "scripting" thing slide when people bring it up, I want to make it clear that they're behind the times and don't know what they're talking about. It's kind of like people saying they won't use MySQL because it doesn't have transactions (it's had them for a while, thank you).
The Perl community has always been rather rotten about marketing and we treat it like a dirty word. However, there's nothing wrong with using it in conjunction with pointing out the technical merits of Perl. There's no way in hell you're going to convince a PHB by tossing "Higher Order Perl" on his desk. That self-same PHB might have a different attitude when he finds out that his programmers are basically writing in a language that should have died over a decade ago.
We can either take a moral "marketing is always evil" high ground and watch while others effectively use negative marketing against us, or we can figure out how to use positive marketing in our favor.
Cheers,
Ovid
New address of my CGI Course.
I define a script as something that looks like a script for a play. That is, it has a list of instructions which should be executed in order. There may be the odd sub-routine, but these are mostly in the same file (of course, with Perl, there may be various calls to CPAN modules, but the code specific to this operation is more or less all in once place). Of course there are no hard and fast rules (i.e. you *could* push some of it into a module), but we're talking about a matter of style here.
One way of writing bad Perl (and there are many, TIMTOWDI applies even here) is to attempt to extend this style for use in applications. I'm sure we've all seen this first hand: huge if/elsif/else structures, requires all over the place, global variables used without regard for the future maintainer's sanity. Some of us (myself included) may have even written code like this.
The scripting style is certain useful for small, fairly self contained pieces of code. Or for one-shot jobs that are again fairly simple. Any other use is probably a bad idea.
I think one reason why people who don't know Perl well have difficulty in understanding the difference between a language that can be used for scripting, and a language that can *only* be used for scripting, is that many languages only allow one style. Perl, of course, allows many.
Additionally, many junior programmers don't really understand the concept of coding style. They just use whatever works. That's why, when you ask them to write a more complex application, they may use the scripting style they've always used.
These things can contribute to a bad (but undeserved) reputation for Perl.
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.
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.
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.
|
- 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
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
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 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
#!/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*
Don Wilde
"There's more than one level to any answer."
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.
Then slowly, step by step, my programs contained more and more percentage of Perl, and then become pure-perl.
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
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.
A collection of thoughts and links from the minds of geeks
The Code that can be seen is not the true Code
I haven't found a problem yet that can't be solved by a well-placed trebuchet
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).
|
- apotheon
CopyWrite Chad Perrin |
"Wait you're trying to sell us an application written in a scripting language?!"
"I'm trying to sell you an application written with the same language as the applications that do Amazon.com's front-end and run Slashdot." (Most of my Perl is for web applications these days).
People who care about buzzwords are followers by nature. So, all you have to do to sell them something that isn't buzzwordy is show them that big, successful organizations are using it. Any PHB who said to me "but customers might complain that it's Perl, and we'll lose business" gets the response "then you need better salespeople".
Yeah, I know -- some people will never wrap their head around it. See, these same people will never listen to anything you have to say about Perl not being a scripting language, either. I find that it's much easier to sell the idea that the scripting/programming dichotomy is a red herring than to argue that Perl is on the programming side. Especially to non-technical people.
Most importantly, I think trying to pitch Perl as though it's buzzwordy is, IMO, selling it far short. Worse, trying to make the argument that "really, Perl is a real langauge" gives credibility to the debate, and so serves nothing but to make the advocate seem mildly pathetic.
Truth be told, Perl is both a scripting and programming language. You can write anything from a tiny, inscrutable one-liner to a full, buzzword-compliant application. For that reason, the debate can never be fully resolved anyhow, and getting into the argument is a lot like fighting the vi vs. emacs war. Then again, I'm one of those people who uses vi and emacs, so maybe I'm just an odd duck…
A collection of thoughts and links from the minds of geeks
The Code that can be seen is not the true Code
I haven't found a problem yet that can't be solved by a well-placed trebuchet
That's why, when someone asks me if Perl is a scripting language or a programming language, I say "yes".
By the way, I'm a Vim guy. Not that it matters.
|
- 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.
|
- apotheon
CopyWrite Chad Perrin |
I'll first make some enemies and some friends here. 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.
Most of the time, a C program is examining some kind of input syntax and deciding what to do. The only degree of difference is in how complex an input language you allow yourself to parse. Either your input language is complex, or you have to parse several times with different syntax subsets to make decisions: your choice.
Many people have attacked this problem, including Larry Wall. His answer is Perl, and, since he is/was a rocket scientist, I tend to think he has a few jets firing in the same direction, generally upward. Other people have gurgitated such things in C/C++ as Lua and Java and VisualBASIC.
Again, your choice. There's always a tradeoff between pure gnat's-burning-@ss speed and ease of development and maintenance. Most of the time it doesn't matter, because a second P-III and a few megs of RAM are blessedly cheap. Perl wins this one in many business equations.
Don Wilde
"There's more than one level to any answer."
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.
"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=)))]'
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 :)
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.
Tom
--
TTTATCGGTCGTTATATAGATGTTTGCA
Agreed, as far as there's a fair chance of introducing a new programming language (in casu: Perl) in your shop. Then again, there's the kind of shops that (usually for reasons of support/maintenance and programmer profiles) standardize on one/a few specific programming languages. I've worked in a context, where only C# was allowed/supported for app. development, -- but where I could develop parts of the solution 3-5 x as easy (=productively, and... interestingly) in Perl, so... I convinced the PHB, that i needed a "small scripting tool" to supplement C#. He signed my order for Komodo, and I could start programming .... eeeehh "scripting", in Active State Perl. Been doing that since, as it best fits into thecurrent app. context.
Allan
Blessed are the meek: For they shall inherit the earth...
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 ;)
This approach does leave an impression. Make it clear that CPAN is part of Perl, and don't challenge anyone who knows Haskell.
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.