Searching for the Best Scripting Language

prostoalex writes "Folks at the Scriptometer conducted a practical survey of which scripting language is the best. While question like that is bound to generate flamewars between the usual Perl vs PHP, Python vs Perl, VBScript vs everything crowds, the Scriptometer survey is practical: if I have to write a script, I have to write it fast, it has to be small (less typing), it should allow me to either debug itself via a debugger or just verbose output mode. sh, Perl and Ruby won the competition, and with the difference of 1-2 points they were essentially tied for first place. Smalltalk, tcc, C# and Java are the last ones, with Java being completely unusable in scripting environment (part of that could be the fact that neither Java nor C# are scripting languages). See the 'Hello world' examples and the smallest code examples. Interesting that ICFP contests lately pronounced OCaml as the winner for rapid development."

Comments

The eternal quest...

[Anonymous Coward]

... for a difinitive answer to a subjective question.

Re:The eternal quest...

[LBArrettAnderson]

What they should have done was make a survey where they ask what peoples needs and wants are. I use perl because I think it's the best solution for my website and it does everything that I need it to do. Other people use PHP because it's easier in certain ways. Someone make a points survey which asks questions about the persons' intelligence, personality, and needs, and that MIGHT tell them what language they should be writing in.

Biased

[javabsp]

I think the author is pretty biased away from Java, at least when compared to C#. If you look at the sample code, the class name for C# is always one letter, but for Java it's always spelled out.

Re:Biased

[p2sam]

for sure! Notice he put in the "public" keyword when declaring the class. That keyword was TOTALLY unnecessary in an allegged quick and dirty script that he claims he was testing.

Re:Biased

[notsoclever]

There's lots of other subtle biases. For example, in the "grep" example, the sh code simply called grep. If he wanted to be pure about the scripting he'd not have had any way of doing a RE in sh (since it doesn't have true RE handling builtin, it only has globs through 'case') and if he was going to use external calls then why didn't he just do 'exec grep "$@"' or otherwise afford the use of external command execution to the other languages too?

Also, in a lot of the Tcl scripts he added in a bunch of "good practice" verbosity which he didn't afford to, say, Perl (similar to the C# vs Java disparities you noticed). For example, in tclsh you don't have to explicitly call 'exec' to call an external function since tclsh provides that as an unknown function handler, and he also used the longhand form of checking for a successful execution (namely 'catch') rather than just doing an if on its result.

Personally, I just use the right tool for the job. I mostly use sh, PHP, and Tcl, depending on which sorts of things I'm scripting, though sometimes I'll also use perl and awk as appropriate (of course, I do often use awk as an external tool from sh).

Re:Biased

[The_Dougster]

That job security through code obscurity thing really doesn't work because the ones who do the hiring and firing probably have no idea what it is you do other than "some computer stuff" and they probably don't have any clue that the whole system is going to crash a couple months after you're gone.

Re:Biased

[RovingSlug]

There's lots of other subtle biases. For example, in the "grep" example, the sh code simply called grep. If he wanted to be pure about the scripting he'd not have had any way of doing a RE in sh ...

"Pure"? What the ... does that mean? The comparison is "how do you solve a problem in a given scripting environment". The comparison is not "what are the precise language features of each scripting language".

In shell, to find a substring in a file, you use grep, not some jackass case statements.

If you must, consider it as comparing the standard libraries between languages. In shell, the standard library is the canonical unix toolset.

Re:Biased

[DissidentHere]

This is certainly true, and not just with obscure code. In a previous job I wrote a number of reporting and work flow applications that saved the company hundreds of thousands of dollars a month. I was the only one in the company who could code (which was not my primary role), so when I got sick of thier shitty treatment I found another job. The COO didn't want to put together a support contract, or even have me come in once in a while for changes and enhancements - he wanted me to maintain the applications for free! Naturally I told them to piss off. It wasn't two weeks before I started getting calls and emails - "how does this work", "We need to change this report" etc. Last I heard they were back to letting a few hundred Gs slip away every month.

The people who make decisions rarely have the background or understanding of technology to make good business decisions. They are perfectly happy to lose a million a year rather than give you a $5K raise. The trick is to find a company with people who appreciate your skills and knowledge.

What about readability?

[BlueCup]

Perl can do a lot, but nothing is more painful than having to look at a perl source code. While a program can be written semi readable, when compared to some others, like PHP or python, they typically make me want to stick very large needles in my eyes.

Re:What about readability?

[DAldredge]

I have seen php code that makes me cry it was so badly written, I have also seen perl code that bad but don't blame the language, blame the idiot who is writing the unreadable code.

Re:What about readability?

[Camel Pilot]

When you press people on perl and readability they usually quote some exacerbating regular expression. Reg exp are often used in perl since they are are handy and built in. And yes, reg exp tend to be a little cryptic. However taking a little time to figure out something like

$str =~ /(.*?)\&(\w+)\((.*?)\)/gis

is a lot easier than understand the 100 lines of code that would be required to accomplish the same task if you where not using a reg exp.

I would be very interested in hearing what you think PHP provides that enhances readablity over perl.

Re:What about readability?

[Nasarius]

Better yet, why not just write a short sentence or two of comments describing what the regex does? This makes it vastly easier to read your code and catch mistakes.

Re:What about readability?

[Our Man In Redmond]

Especially since the first P in PHP stands for Perl (well, it used to anyway, PHP started life as Perl Header Pages).

Readability is a matter of choosing the proper variable names, the proper coding style (e.g. proper indentation) and of commenting properly. Regular expressions have little to do with it. If you have to write a regex that looks like you buy your punctuation at Costco, you should tell the world what it does to make it easier for the next guy down the pike to maintain your code.

Re:What about readability?

[goon america]

I personally would much rather somebody came up with a longhand way to do real regexps. The current way (ie, just one string with some special characters) made sense until people started making much more complicated regexp parsers... now we have to re-use special characters, like the ? can mean 0 or 1 or it can mean non-greedy, or it can mean four other different things depending on where it's used...

I'd much rather have it written out for me in the code what a particular thing is doing, rather than trying to figure out which of the eight different meanings a particular ? could be, much less any of the other pantheon of single-character meaningful regexp modifiers. It's difficult to look up a single character somethingorother like that in a manual. On the other hand, a function name I can look up easily (in the case of php, just type in php.net/function_name and you've got complete documentation in two seconds).

The same finding holds for much of the perl language. The thought in mind for a lot of perl's syntax design is to omit as writing much as possible. The implicit $_, the unless rather than if not, abbreviated versions of everything, like q//, qq//, qx//, etc. The problem is you can't look up something that's been omitted because you don't know what to look for. When exactly can I use the $_ variable? When a program says "shift;", I can't just look up "shift" in the perl manual somewhere, I have to already know about how @_ works in order to understand what the program is doing. I mean, sure, if you already know perl backwards and forwards, and you're the only one that's ever going to see its internals, then I guess it makes sense for you, but for everything else it doesn't.

Re:What about readability?

[louzerr]

I've been slowly drifting from perl to java (completely different, I know), and on those days when I do go back to my perl code, I quite often end up scratching my head, trying to remember what exactly my code is trying to do. So perl fails - no wait! I fail! I tried to be too clever with my code, and did not provide enough documentation.

Then, there's my coworker Steve, who's perl code could be printed out and used for documentation! But then, he starts by writing the documentation as his "plan of attack", and then adds the code.

Long and short, you can't blame the program language for readability, it's really up to the programmer.

Duh

[Beek]

How about the best language for the task you are trying to accomplish?

I've been using AppleScript for a bunch of stuff lately, but when I hit something that wasn't really intuitive in AppleScript that could easily be done in Perl, then I did it in Perl. Obvious, yesno?

Re:Duh

[evilviper]

I don't find it as obvious as you seem to...

Personally, I spend a bit more time trying to prevent wasting resources... Having a bunch of different scripts, all needing a different interpreter, is a nightmare to me.

If you are going to write hundreds of perl scripts, stick with perl if at all possible. And what's more, if it's not possible, I strongly recomend using a compiled language instead of using something else that's going to need an interpreter.

Not only does it waste resources, but it's an absolute nightmare when you need to modify things... Changing something like the file a dozen scripts read isn't too difficult when you are dealing with a single language, but it's quite a mess when 1/4 are bourne, 1/4 are python, 1/4 are perl, and 1/4 are something else that's rather obscure...

You'd be quite surprised by the long and healthy life of some of the simple programs that you write... In the event that your scripts continue to live on for a few years, it becomes more and more likely that they will be needed on strange platforms, or in unusual environments. Maybe the scripts you are writing will be wanted on the CEO's mobile phone, where there is a perl interpreter. If even 1 of those programs that gets called upon is something that can't be used on the device, it will have to be written from scratch at great expense, and all the while probably with people cursing your name for not sticking with one single language...

Perhaps I'm just ranting, but you look at your scripts differently when one simple 5-minute script is in use many years later, and installed on thousands of different machines, where it is called by other programs, from a Windows GUI program, to scripts on a webserver.

Re:Duh

[joib]

How about the best language for the task you are trying to accomplish?


Not necessarily. The problem is that, presuming every problem has a language best suited for solving it, I don't have the time to learn a huge number of languages.

Now, I'm not saying that you should take the only language Real Programmers use, FORTRAN IV, and do absolutely everything with it. What I'm saying is that e.g. if you know python fairly well, I don't think it's worth learning perl just because some simple regexp matching program can be a few lines shorter.

For another example, if doing web stuff is 99 % of what you do and you haven chosen php (because every friggin' webhost supports it, there's lots of ready-made code out there, or whatever else makes people chose such an abomination as php), then using php for some simple non-web stuff is probably a better choice than wasting time learning yet another scripting language.

A kindness

[dedazo]

Perhaps a note along the lines of "for Linux" or "on *nix systems" would have been nice, especially for the thousands of people who read this website, run Windows and couldn't care less about whether or not a language supports "shebang".

So, I RTFA, but I really didn't have to.

it depends upon the application

[humankind]

php for real-time multiuser applications on the high level, C for real performance

perl for non-real-time application (unless you're slashdot and have oodles of resources at your disposal, even then, it's still inefficient)

Everything else: you work for Intel, Dell or Kingston

PHP

[mfh]

I like the ease of PHP and the fact I fully understand it helps. I've wanted to learn Perl, but lack the motivation except to perhaps code some patches for /.

Anyone feel the same way about either PHP or another scripting language? When you fully learn one, is there a need to switch?

Remember, when you have more experience with a scripting language, you can pretty much create anything you'll need at a rapid rate. I think that the level of your knowledge determines the effectiveness of the language.

Re:PHP

[octavian755]

Yeah I feel the same way about PHP.

There are many parts about the language that make it work well for web applications, but there is a time and place for other languages too. For most projects there is no need to use anything else but one language, but if a customer's server only has perl installed and they won't install anything else, then your stuck. So it's a good idea to atleast get to know a couple languages (don't have to master them all) for certain situations like that.

Re:PHP

[davidsturnbull]

Type-specific comparisons, when needed (rarely), can be made using ===/!==, or you can cast variables c-style.
Global variables is complete nonsense, it's true that POST/GET variables can be made global in php.ini, but it's not there by default. Function/class/method scoped variables act as they should.

As to the whinge about modules.. what sort of peon doesn't have their own colocated box these days? They're like $60/mo.

Of course there are real problems with PHP.
The only reason to use PHP is that it's sort of like a loosely-typed C clone, with awesome arrays.

Sometimes you can add $ to all the variables in a C program and it works in php, and mostly you just update a few tiny differences (most of php's unix functions don't have a place for a reference, which sucks btw).

The arrays are nothing short of elite. I haven't seen any more useful array implementation in any other language (although I'd like to find some!)

Re:PHP

[imroy]

PHP: Free Software's answer to Visual Basic.

I think you've got a point there. Both PHP and VB are both languages that us elitists can frown upon and opine things like why do people use such garbage when there are better alternatives? Yes, I'll admit I'm an elitist. But I try not to stray into zealot territory. Zealotry is about emotion and irrational cheerleading. I have (what I consider to be) good reasons for my opinions. And I'm trying to express them here in this thread.

Perhaps the common thread to a lot of these sub-par pieces of software (VB, PHP, MySQL, Windows, etc) is this: Most people appear to be tolerant of software problems if they understand the software (or think they do). Thus the dominance of simple but horid software for the masses. While I'm fiddling about with infrastructure and obsessing over making the perfect framework, some kid is banging out Yet Another PHP/MySQL web site. *sigh*....

My dear lord,

[dotz]

If you want to choose your scripting language by measures like "Program Lengths by Language", "the smallest running program", "access environment variable", "grep with -F -i -h handling, usage, grep'ing many files", then yes, go for it, that report was done for you.

Me? I'd rather choose my scripting *and* programming language by some other measures, which mainly involve:

• portability
• object model
• ease of writing C/asm extensions (for speed!)
• extension modules available in default installation

I have my own choice (not the winner, it's my *choice* - I haven't compared and/or used other ones mentioned too extensivley). I have as portable interpreter, as Java (except it does work, not only claims that), with much smaller footprint; I can code extensions in C using simple syntax (it's very easy); I have already thousands of available modules in the base installation.

I am pretty sure, that other tools, mentioned in the report, also allow pretty much the same, some of them do that better, some of them are worse, some are not worth using (as we seen, network stack can be written in PHP) - that's not the point. In my opinion, that report seems like comparing pneumatic hammers, ordinary hammers, sledgehammers and hamsters (mainly because "hammer" sounds similar to "hamster", so what the heck, let's compare them) - by something like color or shape, not by the things they can do.

You shouldn't compare tools like this (well, except for purely academical purposes), it's not useful at all for me. And, if you want to choose your tools basing on such reports, well then, good luck.

Being small is overrated

[smallpaul]

if I have to write a script, I have to write it fast, it has to be small (less typing), it should allow me to either debug itself via a debugger or just verbose output mode.

A big part of being a scripting language is being quick to code. But it seldom happens that you can tell how quick it was to code by how many characters it was. For instance for some tasks (even some scripting tasks), IDEs can help you go faster. Proper, clear error messages and exceptions can help you go faster. etc. The scriptometer didn't measure time to code at all, even though it is much more important than what they actually do measure.

Also, the definition of "scripting" is totally biased towards sh-based languages. Which language is best for driving a GUI word processor? Which one is best at scraping data from a web site or web service? Which one can tweak an XML configuration file? Which one can transcode from UTF-16 to UTF-8 quickly? Scripting is not just about files and regex filters.

Of course I probably wouldn't bother to post if my favourite language had won...

Re:Being small is overrated

[fireboy1919]

Another thing along those lines is what you get to use from other people. If you can use other peoples code, you don't have to worry about your own.

This is where perl is a big winner over everything else. Nothing else even comes close as far as number of available packages.

I think one of my old professors said it best:
"Nobody likes to write in perl, but it gets the job done."

I'm all geared up to make python and ruby my top picks just as soon as they have something like CPAN I can take code from, or until I start doing stuff that doesn't benefit from other people's code.

MS Conspiracy against Sun/Java

[vijaya_chandra]

The article says the smallest java program is 68 chars long just to make it seem double that of C#
public class smallest { public static void main(String[] args) { } }

But this would be the smallest Java program. only 56 chars

public class A{public static void main(String[] args){}}


(Karma be damned; I am no better than an AC anyway)

Why I like perl

[Anonymous Coward]

I'm going to stick my neck out and say I like Perl -- so I think this is good news. However, I've always thought of Perl as a text-processing language, and In My Limited Experience, mobile phones can only fit about ten words on the screen. {on the other hand, this could simply lead to phones with bigger screens.}

There's no denying that you can write really ugly code in Perl, but you can also write beautiul code in Perl. I think some of the people who knock Perl are confusing "undisciplined" with "not anal retentive". Perl was always based around the idea of serving the end rather than the means -- it's about where you're at, rather than how you got there. It does not impose a particular style on the programmer. Thus, for any given task, there could be many, many ways to accomplish it in Perl.

They're all right.

Some will be faster than others, some will use fewer resources than others, some will look prettier then others when viewed as source. But if you don't care enough about those things to mention them in the design spec, then they don't matter.

Now, you can have your fancy object-oriented stuff, but in many ways it's overkill. For instance, if you needed to write a programme involving geometry, you could create an Angle object which would have a value assumed to be in radians and properties for its sine, cosine, tangent and representation in degrees; a Distance object which would have properties for its representation in different measuring units; and assigning a value to any property would affect the object and therefore its other properties. It might be beautiful if you like the OO concept, but it's a bit overkill if you just want to find the missing side of a triangle.

And does a "disposable" programme -- one that you will run only a few times before forgetting it forever -- really need to look pretty anyway?

As for PHP, well, it really isn't much different from Perl -- apart from always needing to put brackets around function parameters, the fact that all variables start with a $ sign whether scalar, array or hash and there is no $_. {I happen to love $_. It goes nicely with the concept of an accumulator. If you never did any assembly language, you probably won't know what I'm talking about, though}. That is hardly surprising, because the original PHP was actually written in Perl to be like a kind of subset of Perl.

Also, one of my little niggles -- and I freely admit that this is just my own opinion -- is the inability to get on with any language that uses the plus sign as the string concatenation operator while letting you freely mix string and numberic variables. {*cough* ruby *cough*} I expect "2" + 2 to equal 4, not 22. Hell, if I have to do something to my variables before I can add them, that just nullified the advantage of having freely-mixable scalar types! It might as well be a strict-typed language and barf on an expression such as "2" + 2!

As for Python - well, it's not my cup of tea {I guess you like either Perl or Python} but other people seem to have written some pretty good stuff in it, so I shan't knock it.

Wow that's one wacky grading system.

[Retric]

under Tools:
compilation and execution in one command (20 points) vs
debugger (5 points)

Ok, mabe it's just me but the author finds it 4x more important to be able to compile and execute the comand than having a debugger of some sort I mean wow if it's that important maby he should write some sort of script to handle that for him.

And wow that's a lot of TD's out there maby under Program Lengths by Language. Then again maby when we find somone who can figure out that the "ease of converting between numbers and strings" is less important than say noticing that your string doe not contain a number. "10l0" is realy the same as "RED" so who cares right.

PS: If you want to compare scripting lanuages try writing somethign that does a grep search for "GET A CLUE" with files of the format USEFULL*INFO## and then sort's the output by the number of ocurances of "FuncoLand" instead of writing hello world is as few chariters as posible.

These guys aren't fluent in Java...

[arch_helmet]

...Coz you can do this:

public class A{
static{
System.out.println("Hello world");
System.exit(0);
}
}

(How come <ecode> doesn't preserve whitespace?!)

...Which is 95 chars including whitespace and Win$ EOLs.

Not that it makes any difference, Java was never gonna do well and is totally inappropriate for scripting, but there ya go.

--Tim

There's a deeper problem

[Estanislao Mart�nez]

Measuring program size in bytes is stupid. Lines of code, though still rife with problems, is a much better measure.

It's not the language it's the library.

[killjoe]

You know what language does not matter. I can write a preforking server in perl in one line of code. How? Because somebody else has already done it for me, documented the code, posted in a central library that's available for everybody and is searchable. Not only that I can type "perl -MCPAN -e shell" and "install Whatever::Whatnot" and have it in under 5 minutes. Try that with python, ruby, ocaml or java.

Maybe python is easier to read, maybe ruby is more object oriented, maybe ocaml is faster, maybe lisp is better then all of them, but I don't care. When I want to get something done I can always get it done faster in perl and it's all because of CPAN.

Until another language offers what CPAN does I don't care that much about it.

Re:It's not the language it's the library.

[OmniVector]

if that were true, all us linux and mac users should just go ahead and switch to windows. i mean after all it has the largest user based, the greatest number of software titles, the most support, and the most development libraries.

sometimes we prefer to use languages because they are actually easy to code in and read. neither of which perl is good at. and for that reason, it will forever be off my list of languages to consider.

Re:It's not the language it's the library.

[killjoe]

"That doesn't go for scripting languages (as far as I'm concerned), which I don't generally feel are appropriate for large projects."

The topic was about scripting languages.

"There is nothing magic about perl that makes this work."

I used to think that too but I have changed my mind. If there was nothing magical about perl then all languages would have a centralized library of objects and a easy way to download and install them (including dependency resolving). I agree with you that all languages should have this none of them do and there must be a reason for it.

For example. Python and ruby are both MoreObjectOriented then perl. They both have large and active communities. They both have extremely smart and dedicated communities and yet neither one has the equavalent of CPAN. Ruby has an archive at least and python has a half assed repository but all of it poorly documented and can't be installed without manual downloading.

There must be something magical about perl. Don't know what it is but if it was otherwise all other languages would have done it by now. Think about it. This kind of thing is Ideal for java right? It has objects, beans, EJBs etc. Where is big searchable repository of java beans I can download and deploy in under a minute?

Re:flamewar volley 1

[kfg]

Scriptometer survey is practical

Well, for my money, I'm more inclined to start a flamewar over just how they go about defining "practical."

KFG

Re:good but recognized?

[Copid]

As somebody who spends quite a bit of time coding in ruby, I can honestly say that it never got me a job. However, there are times when what you can do with a tool is more important than what other people think you can do with it. I like to think that actual results still matter more than promised results every once in a while.

Which Language?

[TastyWords]

I've collected a paycheck, one way or another, in almost twenty-five languages (in almost as many years) - the ability to learn new things quickly comes in handy when it comes when someone's got obscure code which needs to be rewritten, fixed, or updated.

Big Tip: It's not the language. It's the coder. If you know several languages and can apply the best one for a particular language, it's that much easier. If a language is best-suited for libraries, use it for libraries, then use other languages which are better for GUIs to do that and call the libraries as needed. 95% of the people in the industry really don't belong in the industry and their code basically sucks when you get a good look at it. The problem is people like it and think they're good at it. Because there are so many requests and so few people who can fill the slots, no filtering is really needed compared to what should be done. It may appear things are better now than they were twenty years ago, but the bottom line isn't all that different.

The truly sad part is if you grabbed a large quantity of people who code for a living and put them in a room and said, "All of the good coders go to this side and all of the bad ones go to that side." Which side do you think all of them will go to?

"You don't have to be good, just good enough." (and that's not good enough)

It's what works that counts

[rfc1394]

Every programming languages has its strengths and its weaknesses. PHP is just another (interpreted) version of the C language which is why it's popular (and because it has a module which can be statically linked into Apache.) I presume Perl is popular because it provides fairly complex pattern matching. And there are other scripting languages out there. People will use what they know and what is available to them.

Every job has its requirements; being a good programmer is being able to use the tools you have to solve the problem in a way that fits the requirements. Being a great programmer is knowing which tool is right for the job - and which isn't - and when they may have to look for something else.

Not really a fair test.

[Temporal]

First of all, a pure character-based size count seems unfair. I do not believe that the number of characters in a chunk of source code is directly correlated to the amount of time it takes to write. Most of a programmer's time is usually spent thinking, not typing, and you can thinking just as fast with verbose naming conventions as you can with terse ones, as long as the constructs are the same. And then, if the constructs are different, it's even harder to judge, because if the constructs in one language are more natural, corresponding closely to human thought patterns, then coding in that language will tend to be much faster than coding in more cryptic languages, even if the cryptic language requires fewer keypresses.

For example, I tend to find that writing in functional languages is easier for me. My functional-language just tends to come out faster and contain far fewer bugs. I'm not entirely sure why, but I suspect it has something to do with the thought-pattern-correspondence idea I mentioned above.

Second thought... some of these comparisons are clearly unfair. For example, one of the test cases is implementing "grep". The sh version of this case simply calls grep (after validating the arguments, I guess), which seems like a really big cop-out. Any language could just as easily run grep in a separate process. Meanwhile, the OCaml version seems to implement the main loop of grep manually in terms of library functions that are not identical to grep. That is to say, the main thing the OCaml code is doing is translating grep-specific options and semantics to the options and semantics used by its own library functions. To make this comparison fair, one would have to write a library function in OCaml which is identical to grep, then allow that function to be called without counting the library as part of its code.

I think the only fair and useful way to make comparisons like this would be to hold a contest of some sort. Get an expect Perl programmer, an expert Python programmer, etc., together, then give them a program of some sort to implement. Avoid defining the program to be too similar to one language's library calls. In the end, judge the languages both on how fast the contestant completed the code and on how useful and robust the resulting code turns out to be.

Probably not going to happen, of course.

Re:flamewar volley 1

[prockcore]

Actually, php has the smallest hello world. Anything not wrapped in php tags is passed right through, so "Hello World" in php is literally the length of the string.

Plus PHP supports everything they checked for.. so why wasn't it included?

Rapid Development != Scripting

[Vector7]

> Interesting that ICFP contests lately pronounced OCaml as the winner for rapid development.

Certainly that is interesting, but it has absolutely nothing to do with the subject of the article. "Rapid Development" (or development in general) is not comparable to scripting, and the ICFP contest tasks (which this year was to develop AI code governing ants in a colony) contrast sharply with the sort of scriping tasks in this shootout (compile a file if .o absent, invoke grep on some files, etc).

[aside]

This is not intended to rag on scripting or scripting languages, just to note that scripting embodies a largely distinct set of tasks from development in general (and a comparison involving OCaml or the ICFP contest is inappropriate). These sort of tasks that historically have been the domain of shell scripting, although perl seems to have taken over a lot of these things.

As a lot of what perl is best at is simplifying things that you could almost do from the unix shell (or might be able to do with a script, but would be a pain in the ass..), it always struck me as logical that perl should evolve toward becoming a viable replacement for the unix shell.

Sadly this doesn't seem to be on the agenda of the perl gods. Instead of evolving to better fill this niche, they seem to be gravitating toward becoming a sort of second-rate Java/Python immitator. I suspect that the underlying technologies they build with Parrot and the Perl 6 redesign will largely fail to convince many folks who aren't already perl users that perl is a useful substrate for developing real systems on top of. At the same time they will have neglected to improve in their original niche of quick and dirty sysadmin hacklets, while other languages will have continued to improve and build momentum.

Then again, I'm quite possibly wrong. We'll see what happens. Should be interesting..

Re:good but recognized?

[JamesOfTheDesert]

There are few Ruby jobs, but having it on my resumes almost always leads to a discussion of what it is, why I learned it, and why I use it. It gives me a chance to let the interviewer know more about me, see that I have a genuine interest in CS and software development, beyond simply wanting to know only the marketecture languages and APIs.

Showing that you are self-motivated, and more interested in using the right tool than the "cool" tool, makes an impression

Re:vbscript

[Anonymous Coward]

I was utterly disappointed that Microsoft discarded VBScript when .NET was introduced. The ASP VBScript model under IIS was the only truly innovative product that Microsoft has ever introduced . The ASP VBScript model served it's purpose remarkably well by putting Microsoft on the WWW; without VBScript there would be no Microsoft presence whatsoever (even today, .NET code is 1/10 as common as VBScript on IIS sites).

But Microsoft refused to add those capabilities to VBScript (binary file I/O, associative arrays, throw/catch, etc.) that would have made it a superior scripting language. [Some of these capabilities are currently available through the use of COM components, but COM overhead makes such implementation costly performance-wise - they should instead be part of the VBScript language.] Instead Microsoft developed .NET as a new set of languages that were at once

• an order of magnitude more complex than VBScript and
• that would require the purchase of Microsoft's .NET IDE (veteran VBScript programmers commonly use NotePad as their IDE).

This is an unfortunate but compelling example of a corporation shooting itself in the foot by discontinuing enhancement of a successful product.

So in summary,

[NorthWoodsman]

Sh is the best at doing tasks common in Sh, whereas languages not designed for shell scripting do them less well than sh. Furthermore, languages that aren't even scripting languages are terrible at being sh.

Ocaml isn't a scripting language either!

[bhurt]

While it does moderately well on this test (finishing near the middle), you might be surprised at it's weak finish compared to it's reputation as a concise language. Well, as a committed Ocaml advocate, Ocaml isn't a scripting language. I freely admit that it has so-so string handling, no built-in regular expressions, so-so process handling, etc. But this is because it isn't a scripting language- it's an applications language, like C++, Java, and C#. And the only reason it does as well as it does is because it's a signifigantly better language than it's competition.

If you're writting a quick script to grep through the log files looking for port scanners, Ocaml is the wrong language.

Brian

You're missing the point.

[Estanislao Mart�nez]

The measure that the comparison is applying is the size of the source code in bytes. If we're talking about the size of the executable, (e.g. bytecode in Java, C# or Python), bytes is the natural measure.

Point being?

[warrax_666]

What's your point? The program is shorter shorter when written in sh, more natural and more readable. (Not to mention that it uses lazy evaluation, so that the full input doesn't need to be in memory, just the full list of words).

Practical? Bah, humbug. (Pythonic bias warning.)

[AlexLibman]

As much as I love programming language comparo's, this one just doesn't hit the spot. Do people actually think a scripting language should only be used for tiny write-only stand-alone scripts? TOOLS: If this section was meant to cover the tools / features that enhance the versatility and convenience of a language, it isn't complete. What about machine code compiler availability / VM support, Web options (CGI, Apache plug-in, Server Pages, etc), editor / IDE support, profiling, RAD features like unit testing, and docstrings, multiplatform support for threading and other features that immature languages might leave POSIX-centered, etc? License openness and multiplatform range should also be considered. And why is shebang awareness, working without which would just require one extra word on the command line, three times more important than an interactive interpreter, debugger, or passing program in command line, which open up some serious time-saving habits. SPEED: Unlike compiled / system programming languages, interpreted speed isn't the most important feature of a higher-level / scripting language. For most tasks on a modern computer, development time is infinitely more precious than execution time. Algorithms matter more than the overhead language speed. For example, since many scripts spend much of their time waiting for file I/O, network response, or user input, a Perl programmer who understands multithreading might end up writing faster apps than a C programmer who doesn't. Another important point is how a language fits into a large modular system. For example, Tcl is easier to embed / extend with C than many of the languages compared, so the real-world apps that are implemented in a combination of C/C++ and Tcl can be optimized as much as is needed. Python has superior profiling, JIT machine code compilation, and VM (IronPython, Jython) implementation than most / all of those scripting languages. Final speed note: the Python version 2.2 used in those benchmarks is ~30% slower than the latest version. L.O.C. COUNT: Program briefness shouldn't be the only measurement of sample code: productivity and readability are each at least equally as important. Like, even though Perl is more compact, I'd bet those sample Python scripts would take less time programmers to write, and far less time to read for a non-Perl-centered programmer. The benchmark should also define a common policy for abbreviation-vs-readability in sample code: many of those examples could be made briefer or more readable regardless of the language. The comparison was missing a number of essential sections: LANGUAGE QUALITIES: how the fundamental language features impact its abilities as a scripting language. This would include language agility, dynamic typing system, garbage collection, high-level non-scalar objects (arrays, hashes, tables, relational features, etc), OO / multi-paradigm abilities, etc. How easy is the language to learn? (Will your non-programmer users be able to make trivial changes themselves?) Does it have any unavoidable annoyances (ex. as much as I love Python's use of whitespace, lack of an alternative block syntax would be a minus here). SCALABILITY: Can it be used for very large applications? Does it break if running more than X instances / threads / CGI hits / etc at the same time? Does it break when asked to allocate 20 gigs of memory for some fancy chemistry simulation with lots of large numbers? AVAILABILITY: How frequently is a language available on a typical shared Web host? How many add-on packages / libraries are available? Does it have any gaps in its library offerings: well-rounded RDBMS support, GUI, regex, multithreading, etc. How easy is it to find related published books, online tutorials / references, and community help? Is there a quality-assured version (like ActiveState), without which a language may not be usable in some commercial situations? Are there many popular / killer-app projects that use the language (ex. Zope). Finally, the comparison was missing PHP, which has full

Hello, 'Best tool...'?

[soccerisgod]

What ever happened to the engineer's motto "The right tool for the right job"? I'm not a scripts person, but indubitably, all scripting languages have their specific advantages for specific applications. Imho, this whole thing is made for trolling and flaiming and not for anything else. It's just stupid.

From a pragmatic point of view...

[Not_Wiggins]

the "correct" answer is easy: the one you know best.

Unless you have other considerations like maintainability, reuse by coworkers, etc. But those considerations are external to any language you might choose.

They wanted Perl to 'win'.

[Qbertino]

What a silly way to try and display 'objectiveness'.
I get the strong feeling some Perl freaks were involved in the evaluation tables design.

Where's readability?

Could it be that readability contradicts with 'programm shortness'?
Ever tried to read through the shortest possible Perl solution to a problem? Exchange shortness for readability and Python will porbably 'win' hands down.

And what silly dork drew the line between 'scripting languages' and 'programm languages' ?? With 'Java not being a scripting language' and Python, Perl and Ruby being one. Whatever that's supposed to mean.
Why this evaluitation may be objective on some narrow areas, in a whole it's somewhat pointless. I can add some other criteria that will have TCL or bash win in no time.

Re:Learning how CPUs work

[bwalzer]

The original poster said that learning Forth would help you understand how computers work, not just the CPU bit.

Since doing stuff with the Forth environment involves lots of interaction with bits you tend to learn a whole lot about binary math/logic quickly. Since the virtual machine is understandably simple and different from traditional computer architectures you end up at a place to start thinking about computer architectures. Since Forth is a reasonably productive programming environment you learn that a lot of the stuff they teach you in Computer Science is probably wrong...

You were talking about the "what" of computers. Exposure to non-traditional environments like Forth gives you a start on the "why" which is a hard thing to come by in the somewhat dogmatic world of computers.

Bashless systems?

[Pan T. Hose]

That's bash code, not sh.

The examples in the article use bash. They note that the implementation of sh that they use is bash.

I overlooked that bit. But I didn't notice any bashisms in their code, and it's rather surprising how many bashless systems I've had to deploy existing scripts on (requiring some porting in many cases).

This is hardly an argument against Bash--now is it? Even despite the obvious lack of omnipresence of Bash, I would bet it is still much more popular than Merd, Lua, OCalm or even Haskell which were also evaluated in the article.

I have seen more perlless than bashless systems myself. I have seen lots of systems with Perl 4 (there are still new systems shipped with Perl 5.005 (sic!) today which is so 1998) but I would not consider using only Perl 4 syntax in the Scriptometer test because of that.

Nevertheless, having done it myself too many times, I can perfectly understand your pain in porting shell scripts. As Larry Wall once said, "it's easier to port a shell than a shell script."

Actually, I don't know of many systems to which Bash has not yet been ported. The systems with Bash I know of are GNU/Linux, FreeBSD, OpenBSD, NetBSD, BSD/OS, BeOS, Sun Solaris, IBM's AIX, SGI, HP-UX, Compaq's Tru64 Unix, Jaguar/MacOS X--just from the top of my head. I would consider it a very strong argument pro Bash.

To be honest, I don't know what would you expect from a Bash script grepping text file in the linked article. Running an external grep is apparently not good enough even though running external programs is essentially what shells are supposed to do... Fair enough, so I have written a pure Bash script, which in turn is still not good enough since it is a Bash script... Well, I rest my case.

If you know Chinese...

[jotaeleemeese]

.... to read Chinese is a real fucking peace of sugary cake.

Well, Duh!

Perlmongers believe that everybody is fluent in Chinese.