Slashdot stories can be listened to in audio form via an RSS feed, as read by our own robotic overlord.


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Searching for the Best Scripting Language 673

Posted by michael
from the less-filling!-tastes-great! dept.
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."
This discussion has been archived. No new comments can be posted.

Searching for the Best Scripting Language

Comments Filter:
  • by Anonymous Coward on Saturday June 12, 2004 @10:33PM (#9410740)
    Hello, I am the Slashdot Source Code. The answer is Perl. This question is now answered.

    Thank you for visiting Slashdot.
  • by Anonymous Coward on Saturday June 12, 2004 @10:34PM (#9410746)
    ... for a difinitive answer to a subjective question.
    • by LBArrettAnderson (655246) on Saturday June 12, 2004 @10:36PM (#9410762)
      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.
    • by DavidNWelton (142216) on Sunday June 13, 2004 @02:20AM (#9411735) Homepage
      My friend Salvatore and I did a similar site, although we haven't added so many languages and tests, and are more focused on benchmarking. It's available at: []
      • by mtsv01 (688338) on Sunday June 13, 2004 @02:35PM (#9414679) Homepage
        Another interesting comparison of programming languages is "An empirical comparison of C, C++, Java, Perl, Python, Rexx, and Tcl" []
        The interesting conclusions are:
        • Designing and writing the program in Perl, Python, Rexx, or Tcl takes no more than half as much time as writing it in C, C++, or Java and the resulting program is only half as long.
        • No unambiguous differences in program reliability between the language groups were observed.
        • The typical memory consumption of a script program is about twice that of a C or C++ program. For Java it is another factor of two higher.
        • For the initialization phase of the phonecode program (reading the 1 MB dictionary file and creating the 70k- entry internal data structure), the C and C++ programs have a strong run time advantage of about factor 3 to 4 compared to Java and about 5 to 10 compared to the script languages.
        • For the main phase of the phonecode program (search through the internal data structure), the advantage in run time of C or C++ versus Java is only about factor 2 and the script programs even tend to be faster than the Java programs.
        • Within the script languages, Python and in particular Perl are faster than Tcl for both phases.
        • For all program aspects investigated, the performance variability due to different programmers (as described by the bad/good ratios) is on average about as large or even larger than the variability due to different languages.
  • by nocomment (239368) on Saturday June 12, 2004 @10:34PM (#9410749) Homepage Journal
    where's php?
    print "hello world";
    • by kfg (145172) on Saturday June 12, 2004 @11:13PM (#9411008)
      Scriptometer survey is practical

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

    • Re:flamewar volley 1 (Score:4, Interesting)

      by TheRealMindChild (743925) on Saturday June 12, 2004 @11:32PM (#9411131) Homepage Journal
      VBScript is mentioned, but I dont see it anywhere on that page

      MsgBox "Hello World"
    • by prockcore (543967) on Sunday June 13, 2004 @12:11AM (#9411300)
      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?
      • Re:flamewar volley 1 (Score:5, Informative)

        by JWSmythe (446288) <[moc.ehtymswj] [ta] [ehtymswj]> on Sunday June 13, 2004 @04:12AM (#9412022) Homepage Journal
        But they probably would want it at least in the language, so it would be:

        <? print "Hello World" ?>


        <? echo "Hello World" ?>

        They probably should have included it, but that would add quite a few other "web" scripting languages, as long as they have a way to run them locally. Off the top of my head, I'm thinking ColdFusion, I'm sure there are more.

        I think a fun game would be to find the longest way to print "Hello World", without unnecessary filler functions or comments. My first attempt would be to have the Base64 encoded string as a variable, then decode it, then print it, and have all that in an encoded eval.

        I found a script someone had that did their "protection" that way. Without the registration key, you couldn't run it, and they had this beautiful set of encoded strings in evals that did the checking. Took me a good 20 minutes to figure the whole thing out. Then I rewrote that part, so I could try the software without a working key. :)

        The software was otherwise crap, except for all the work they had put into requiring the key. I tried it, and proceeded to delete it. It would have been nice if they had a shareware version to try first. I'm really glad I didn't spend the $200 they wanted for it.

  • Biased (Score:4, Insightful)

    by javabsp (591265) on Saturday June 12, 2004 @10:38PM (#9410777) Homepage
    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 (Score:5, Informative)

      by jelle (14827) on Saturday June 12, 2004 @10:49PM (#9410865) Homepage
      One-letter class names? Is he nuts? That guy never had to maintain code I guess...

      • Re:Biased (Score:5, Funny)

        by Martin Blank (154261) on Saturday June 12, 2004 @11:23PM (#9411076) Journal
        No, no... He values maintaining a job. With one-character class names, he's the only one that can really trace the workings. Ergo, he's the only one who can maintain it, and thus unfireable.
        • Re:Biased (Score:5, Insightful)

          by The_Dougster (308194) on Sunday June 13, 2004 @12:08AM (#9411283) Homepage
          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 (Score:3, Funny)

            by Mad Marlin (96929)
            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.

            Which is when they realize how good of a programmer you are, and hire you back for twice your previous salary.

    • Re:Biased (Score:3, Insightful)

      by p2sam (139950)
      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.
    • Measuring program size in bytes is stupid. Lines of code, though still rife with problems, is a much better measure.
    • Re:Biased (Score:5, Insightful)

      by notsoclever (748131) on Saturday June 12, 2004 @11:18PM (#9411049) Journal
      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 (Score:5, Interesting)

        by the gnat (153162) on Sunday June 13, 2004 @01:00AM (#9411492)
        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

        Interesting - I hadn't noticed this. Personally, I ALWAYS code Perl with 'use strict', because I've had so many bad experiences with larger scripts that were undecipherable and/or had nasty bugs due to variable mispellings. I avoid using shortcuts whenever possible.

        I think these comparisons are largely bullshit anyway. Many of these programming languages have their own tics or methodologies that appeal to subsets of people. Quite a few people I've talked to (and quite a few posters here, from past experience) are annoyed by Python's syntactical indentation. Since I think everyone should be indenting their code perfectly and consistently anyway, even C or Perl, I love this feature. On the other hand, Python is too slow for some of the simple tasks I need done.

        I don't think you can apply these comparisons broadly either; the code I write in scripting languages includes everything from cleaning up files and batch scripts, to text parsing, sequence alignment, and protein structure calculations. Since at least half of the code I write will never be seen or used by anyone else, I use whatever I think will get the job done fastest AND be the most fun to code in. And if I ever make someone maintain my AWK code, I'll fully expect to be thrown off the roof.
        • Re:Biased (Score:5, Interesting)

          by notsoclever (748131) on Sunday June 13, 2004 @02:04AM (#9411696) Journal
          On the subject of syntactic indentation, there is one very specific place where Python's syntactic indentation can easily burn you, and that place is Slashdot. Or any web-based forum which makes formatting a simple chunk of text difficult, for that matter.

          One time a few years ago on some webboard I was debating with someone about the merits about syntactic formatting and so on, and he whipped out the usual strawman about "well, which is more understandable, this or this?" and of course, the (whatever the other language was) version would still run just fine (and the formatting could be easily recovered by anyone who cared to), while the Python version was totally worthless specifically because even a human couldn't recover the control structures without the formatting!

          Decent code editors like Emacs and XCode and so on make the indentation easy to maintain, and easy to recover on most languages. But there is no way in hell that you can automatically recover the formatting on a language where the formatting itself is *part* of the language.

          Anyway, yeah, 'use strict' (or its equivalent) is a must. Tcl enforces that by default (is it obvious that I have a thing for Tcl yet?), and it's easy enough to do in PHP as well (with ErrorReporting(E_ALL) or whatever). I have no idea why any programmer in their right mind would deploy a web application which makes assumptions about the default values of variables; many times I've been working on other peoples' PHP scripts which played fast and loose with global variables and automatic registration and so on and they were so full of security holes and REALLY difficult to debug. Like, it's happened way too often that I've been unable to figure out why a variable wasn't getting set only to discover that it was misspelled in its assignment or something.

  • by Dimwit (36756) * on Saturday June 12, 2004 @10:38PM (#9410778)
    Two languages missing are:

    Io [], which is an awesome, prototype-based scripting language that's super-easy to embed in C applications, and has an incredibly simple and consistent syntax.

    REXX [] (Regina's just one implementation). REXX makes it incredibly easy to do system scripting, with powerful string-manipulation and I/O redirection.

    Another one's ficl [], which is basically an embedable Forth interpreter. (To all you young geeks out there - LEARN FORTH. You may never need to write a line of it ever in your life, but you'll learn a hell of a lot about how computers work. Trust me on this.)
    • by quantum bit (225091) on Saturday June 12, 2004 @11:18PM (#9411048) Journal
      Another one's ficl, which is basically an embedable Forth interpreter.

      Random bit of trivia: The FreeBSD boot loader has a slightly cut-down version of ficl embedded (and all the boot/kernel loading logic is written in Forth).
    • by Almost-Retired (637760) on Saturday June 12, 2004 @11:45PM (#9411190) Homepage

      I haven't coded any job in anything but bash recently, but the most productive code I ever wrote or helped write was in ARexx on an amiga. FWIW, nearly 10 years later, that machine is still doing its job at WDTV-5, running an ARexx script I helped write, which itself is being run by a Cron Jim and I also wrote in ARexx, then compiled to standalone binary with rexxplus. You can see its output on the web page at under the news category. Its converting the rather laughably formatted teleprompter scripts to news stories you can read, as best it can with limited source information.

      Surely it (REXX) deserved at least an honorable mention.

      Cheers, Gene
    • by SSpade (549608) on Sunday June 13, 2004 @12:02AM (#9411258) Homepage

      Forth? No.

      Learning forth will help you learn reverse polish notation, one specific trick for building high-performance interpreted languages and a very lightweight, easily extensible and embeddable scripting language.

      It won't, though, teach you anything about computers work beyond the small amount you'll pick up by learning any new language. Including French.

      If you want to learn how computers work there are far better things to play with. Assembly language [], obviously, whether it be a synthetic assembly language such as DLX or a real architecture. x86 isn't the most enlightening assembly language to start with (6502 is excellent, MIPS or for a really nice architecture, Alpha) but it'll run on your PC.

      Books. Patterson and Hennesey, Computer Organization and Design, The Hardware/Software Interface is pretty good for a programmers intro, but Hennesey and Patterson, Computer Architecture, A Quantative Approach will teach you a lot more, as will most texts with Superscalar in the title

      Learn a hardware description language. Verilog [] is better, but VHDL is OK. Compilers and simulators are freely available [] for both.

      Get an FPGA development kit. Compile yourself some hardware. You can put full CPUs [] on a fairly cheap FPGA development board.

      Design your own CPU. It's possible for an individual or a small group to design a CPU [] and have it fabricated as a tinychip. I've seen individuals design a full, if tiny, CPU at mask level in a couple of months, and a small group put together a fairly decent gate level design in a few more. Commonly done as part of a college course, but an individual can have a tinychip fabricated for around $1000. Not cheap, but cheaper than some hobbies.

      You can do full circuit level design and simulate it using either gate level or spice transistor level simulators and see just why addition or multiplication takes as long as it does.

      As a general rule I've found that some of the best software engineers have some hardware design background, and a good understanding of computer architecture, so even if you never plan to do any hardware design, understanding how it all works is a good idea.

      Of course, I've also found that a large fraction of good software engineers have also spent time working as theatre technicians, so who knows what the correlations are...

    • Last I looked at it, Io wasn't quite ready for the prime time. It looks like it has moved forward some since then, but in the way of being useful, libraries and the like, it still lags behind a lot of the medium- and big-languages.

      Beyond Io, what would be the scripting language with a primarily prototype-based OOP system with the most usage and libraries? I know of a handful of similar languages, but not sure which one would make the most sense from the standpoint most potential scripters are coming from
  • good but recognized? (Score:3, Interesting)

    by 2057 (600541) on Saturday June 12, 2004 @10:39PM (#9410787) Homepage Journal
    Ruby came in second, now lets say i put Ruby on my much respect will that get? while it was useful to rank the scripts to the author for whatever purpose(prove his point). It is still useless because there is a lack of implentation of 90% of these scripting languages...ergo this changes resume is still filled with useless knowledge which won't help me win on jeopardy
    • by archen (447353) on Saturday June 12, 2004 @11:10PM (#9410993)
      That depends. I've heard that Ruby is already more popular in Japan than Python. Much of the ports system in FreeBSD (like portupgrade) is written in Ruby. The fact that Ruby is a pretty young language and has already gained so much support tells much of how good it is. While it might not be quite so useful for a resume, it is good for getting results. I know where I work they don't care about the details, they just want results. Right now I write things in perl, but I have the feeling that once perl 6 comes into the mainstream, I'll be moving to Ruby. You don't have to get very far into the language to realize it's very powerful for writing quick scripts, and can scale VERY well. Aside from that it has taint checking which is also a plus - it's certainly worth it just for doing your own tasks if nothing else.
    • by Copid (137416) on Saturday June 12, 2004 @11:24PM (#9411085)
      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.
    • by CatGrep (707480) on Saturday June 12, 2004 @11:50PM (#9411207)
      now lets say i put Ruby on my much respect will that get?

      I just hired my replacement for a contract I was doing (I accepted another offer that was more in line with my field). One of the requirements was that the person hired would have to know Ruby because much of the code base was in Ruby. They hired someone from our local Ruby User's Group.

      So to answer your question: for this particular job if you didn't have Ruby on your resume it wouldn't get a second look. If you had Ruby on your resume, but it became apparent in the interview that you didn't know Ruby... well, the interview was over.
    • by JamesOfTheDesert (188356) on Sunday June 13, 2004 @12:18AM (#9411324) Journal
      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

  • by BlueCup (753410) on Saturday June 12, 2004 @10:39PM (#9410788) Homepage Journal
    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.
    • by DAldredge (2353) <SlashdotEmail@GMail.Com> on Saturday June 12, 2004 @10:53PM (#9410892) Journal
      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.

    • by Camel Pilot (78781) on Saturday June 12, 2004 @11:29PM (#9411116) Homepage Journal
      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.

      • by Nasarius (593729) on Sunday June 13, 2004 @12:34AM (#9411390)
        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.
      • by goon america (536413) on Sunday June 13, 2004 @02:07AM (#9411704) Homepage Journal
        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 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.

    • by louzerr (97449) <Mr,Pete,Nelson&gmail,com> on Sunday June 13, 2004 @07:09AM (#9412375) Homepage
      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 (Score:5, Insightful)

    by Beek (10414) on Saturday June 12, 2004 @10:40PM (#9410793) Homepage
    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 (Score:3, Insightful)

      by evilviper (135110)
      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 absolu
    • Re:Duh (Score:5, Insightful)

      by joib (70841) on Sunday June 13, 2004 @04:03AM (#9411993)

      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.
  • by humankind (704050) on Saturday June 12, 2004 @10:45PM (#9410837) Journal
    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

  • Discrepancy... (Score:3, Interesting)

    by Polo (30659) * on Saturday June 12, 2004 @10:45PM (#9410838) Homepage
    The slashdot descripton mentions that OCaml is the best. ...But when you follow the link, and look at the bottom of the page regarding the first prize winner, This [] is the proclamation.

    It's not OCaml.
  • C++ (Score:3, Funny)

    by daserver (524964) on Saturday June 12, 2004 @10:45PM (#9410839) Homepage
    C++ was also praised: "C++ is a fine programming tool for many applications."
  • Scripting with Java (Score:3, Informative)

    by los furtive (232491) <ChrisLamothe AT gmail DOT com> on Saturday June 12, 2004 @10:45PM (#9410840) Homepage
    If you'd like to try scripting with Java, then I suggest looking into Mozilla Rhino [], which allows one to script Java via JavaScript.
    • by Teckla (630646)

      If you'd like to try scripting with Java, then I suggest looking into Mozilla Rhino, which allows one to script Java via JavaScript.

      Rhino is a JavaScript interpreter written in Java, it's not a Java interpreter.

  • PHP (Score:5, Insightful)

    by mfh (56) on Saturday June 12, 2004 @10:45PM (#9410841) Homepage Journal
    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 (Score:4, Insightful)

      by octavian755 (588429) on Saturday June 12, 2004 @11:14PM (#9411021) Homepage
      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 (Score:3, Interesting)

      by imroy (755)

      It's been a number of years since I've programmed heavily in PHP. I had learned Perl first, and it eventually took over. If you do learn Perl I think you'll discover the language that PHP is trying to be. Which isn't surprising, considering that PHP originally started off as a perl CGI script. The problem with PHP is that there doesn't seem to have been a lot of thought put into the design of the language. A prime example is the way that Perl has seperate numrical and string comparitors (==/!= and eq/ne) w

      • Re:PHP (Score:4, Interesting)

        by Tarantolato (760537) on Sunday June 13, 2004 @12:16AM (#9411317) Journal
        PHP is a mess of a language. It really is.

        PHP: Free Software's answer to Visual Basic.

        (Not a troll, seriously: they're both mind-bendingly hideous, oversimplified hacks that just happen to be ubiquitous because they make life easier for a lot of people.)
      • Re:PHP (Score:3, Informative)

        by jpkunst (612360)

        A prime example is the way that Perl has seperate numrical and string comparitors (==/!= and eq/ne) whereas PHP has only the one (==). This recently came up in the story about the Perl periodic table of elements and I even gave my own answer on this problem. Just to rehash: Perl and PHP are loosely-typed languages so the programmer really needs to tell the interpreter how to compare the mixed numerical/string "scalar" type that both Perl and PHP use. But PHP tries to simplify at the expense of introducing

  • by rsidd (6328) on Saturday June 12, 2004 @10:46PM (#9410846)
    It's an incredible language. I'm writing programs now that are more concise than the Python equivalent and about as fast as C. It's really the holy grail I was looking for. (According to a more thorough shootout [], ocaml is competitive in speed with C and often faster than C++, and well ahead of all other competition in speed.)

    The flip side is that before becoming productive one has to get used to a whole new way of thinking about problems: immutable data, everything is a function evaluation, no sequential statements, no side-effects, rely on recursion as much as possible, especially tail-recursion. But ocaml isn't religious about it: it has imperative features, including for and while loops, sequential statements (essentially successive function calls with side-effects and null output), and so on. After a while, though, you find you hardly need any of that. Maybe it's just me, but the sort of work I do is well suited to the functional approach. Also, it has a rich set of data structures and is pretty much agnostic about them: you can use linked lists, hashes, mutable arrays or records, sets, whatever suits your purposes.

    The other drawback is the libraries (modules) aren't as complete as the Perl and Python equivalents (though far ahead of most other competition). I imagine that will get cured with time.

    • by pikine (771084)

      I use O'Caml for about two years now, and I like it immensely. I also know Perl. When I compare the two, I'd say the problem with O'Caml for scripting is that it's more cumbersome to write regular expression matches in O'Caml than in Perl. And I have to say being able to write regular expression matching easily really is the key to many scripting tasks that I'm aware of (not necessarily what I do).

      There is a remedy though. O'Caml comes with camlp4, a Pre-Processor-Pretty-Printer, which basically lets you

    • by gauchopuro (613862) on Saturday June 12, 2004 @11:06PM (#9410972)
      I suggest you also take a look at Haskell [], if you have not done so already. Haskell completely does away with side effects, performing IO operations in a controlled manner through the use of a mathematical concept known as monads. It also adds lazy evaluation. This has some nice capabilities, such as being able to express concepts as infinite lists, which are then only evaluated as far as necessary.

      I have used OCaml a bit, and one of the things that most irritated me about it was its complete lack of operator overloading; having to use "+" for integer addition, and ".+" for floating point addition, just seems so wrong to me. Haskell uses type classes to allow ad-hoc polymorphism in a controlled manner.

      One advantage that OCaml has over Haskell is speed; current Haskell implementations produce code somewhere between imperitive compiled languages and interpreted languages. However, there is another language, called Clean, that is nearly identical to Haskell in many ways, but claims to have speed comparable to C.

      Back to the topic of the discussion, Haskell is probably not the best choice for quick and dirty one time scripting uses. The use of monads for doing IO adds a constant cost that is burdensome for very small programs, and gets payed back only with larger programs where the controlled approach to IO increases robustness.

      • by wirelessbuzzers (552513) on Sunday June 13, 2004 @12:16AM (#9411315)
        I suggest you also take a look at Haskell, if you have not done so already. Haskell completely does away with side effects, performing IO operations in a controlled manner through the use of a mathematical concept known as monads. It also adds lazy evaluation. This has some nice capabilities, such as being able to express concepts as infinite lists, which are then only evaluated as far as necessary.

        Yes, lazy evaluation can be done in OCaml too, but the syntax is uglier. You use the lazy module.

        I have used OCaml a bit, and one of the things that most irritated me about it was its complete lack of operator overloading; having to use "+" for integer addition, and ".+" for floating point addition, just seems so wrong to me. Haskell uses type classes to allow ad-hoc polymorphism in a controlled manner.

        Haskell's solution to the problem is ingenius, but unfortunately very often requires tagging of those classes, which is slow.

        One advantage that OCaml has over Haskell is speed; current Haskell implementations produce code somewhere between imperitive compiled languages and interpreted languages. However, there is another language, called Clean, that is nearly identical to Haskell in many ways, but claims to have speed comparable to C.

        Looks like Clean has a more powerful set generator than Haskell (it's basically SQL queries), a different class system, and rather different syntax. But it could be useful, I'll check it out.
    • by srussell (39342) on Sunday June 13, 2004 @08:21AM (#9412564) Homepage Journal
      This is not flaimbait: I'm honestly curious.

      About six months ago, I decided I needed to re-learn functional programming, so I did a project in Haskell and learned that. More or less. I still find Modads awkward, and IO is a total pain in the ass, but all in all, I really like Haskell. However, at some point, I noticed the performance issues; Haskell is pretty slow -- slower than some scripting languages, like Ruby, for a lot of tasks.

      So then I looked at OCaml, because OCaml has a reputation for being fast, and it is also a functional programming language that compiles to native executables.

      I have to say, my first (and lasting) impression was: WTF? Look at this:

      1 + 1 (* Add two ints *)
      1. +. 1. (* Add two floats. WTF? Why?
      Is the compiler so stupid that it
      can't recognise floats? *)
      1 + 1.0 (* Error! *)
      1 +. 1.0 (* Error! *)
      let f x y = x + y (* Define a function *)
      let rec f x y = f (x-1) y (* Define a recursive
      function. Again, why? *)

      Why do I have to *tell* the compiler that the function is recursive? The compiler is able to do inferrence type checking; why can't it tell that a function is going to recurse? In fact, why is there "let" anyway? Seriously, the compiler should be able to figure these things out. Haskell's compilers do. And did they decide to end lines with two semi-colons just to add keystrokes? Why? Why? Why?

      The simple fact is that Ocaml requires the programmer to do a lot of the compiler's work for it. I find this to be the most annoying feature of any programming language. Ocaml gets rid of some stupidities, like variable type declarations, but it adds all of this other stupid syntactic cruft that shouldn't be necessary.

      OCaml is popular. It is efficient (lines of code), and it creates fast executables (second only to C). There are a lot of reasons to love it, and I feel obligated to learn it, but I'm having a hard time getting over what superficially appear to be poor language design decisions. So, is there a good reason for the extra syntactic oddness in OCaml, or is it just there because it always has been?

    • by CoughDropAddict (40792) on Sunday June 13, 2004 @10:24AM (#9413187) Homepage
      I've tried learning OCaml a few times, and my biggest gripe with it was the syntax. One problem was that it seemed like every time I managed to wrap my head around a new syntactic construct, the tutorial would say "since that's too long to write, we use this shorthand to mean the same thing." So now I have to learn a new construct that does the same thing but also try to remember how it relates to the longer version.

      Another problem is that there is very little punctuation that gives your eye any aid in seeing structure. Very often you get a bunch of keywords and identifiers in a row with no delimeters at all! A simple example of this from the tutorial:

      let cos2 = compose square cos;;

      Come on, cut me some slack! Is this compose(square(cos)) or (compose(square))(cos) or compose(square,cos)? I shouldn't have to think about precedence rules when I'm reading a function call, the syntax should make it clear what's going on! Another example:
      let rec member x btree =
      match btree with
      Empty -> false
      | Node(y, left, right) ->
      if x = y then true else
      if x < y then member x left else member x right;;
      Compare this with a Python-like syntax:
      let member(x, btree):
      case Empty: False
      case Node(y, left, right):
      if(x = y): true
      elif (x < y): member(x, left)
      else: member(x, right)
      I don't know about you, but to me the second example is a lot more readable. Readability is about making your eye see the structure without even trying. That's one of the reasons I like Python so much: I think it excels at making the structure unavoidably apparent.

      Ocaml's definitely got some cool things going on, and I really respect the fact that smart people seem to gravitate towards it and get useful things done with it. If I ever learn it, I'm going to have to suck it up and deal with syntax I really don't like.
  • My dear lord, (Score:5, Insightful)

    by dotz (683519) on Saturday June 12, 2004 @10:48PM (#9410855)
    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.

  • by smallpaul (65919) <[ten.docserp] [ta] [luap]> on Saturday June 12, 2004 @10:49PM (#9410863)

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

    • 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 unt
  • by krumms (613921) on Saturday June 12, 2004 @10:55PM (#9410909) Journal
    But it really does depend. I'd use Perl over Python for web development any day of the week (exception: Zope seems pretty cool, but I've not fooled with it enough. The 'everything is an object' metaphor is heaps cool though :)). Perl is faster to write and more expressive, Python is easier to read and - IMHO - often better structured.

    PHP is great for hacking web stuff together, but ... yeah ... the language itself seems a little hacked together - PHP5 fixes a lot of things, mind you so my opinion might change in a few months time after I've used it a little more.

    It worries me that a "feature complete" version of PHP instantly becomes a release candidate, rather than stewing in Beta for a while.
  • pulling a Tcl boner (Score:4, Informative)

    by Anonymous Coward on Saturday June 12, 2004 @10:57PM (#9410919)
    His Tcl example is not written fairly. The dude should know that that Tcl supports getopts:

    package require GetOpts 1.1

  • No PHP? (Score:3, Informative)

    by Anonymous Coward on Saturday June 12, 2004 @10:57PM (#9410920)
    I don't see PHP listed. It's possition on the list is arguable, but it certainly belongs there.
  • Why I like perl (Score:5, Insightful)

    by Anonymous Coward on Saturday June 12, 2004 @11:02PM (#9410952)
    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.
    • Re:Why I like perl (Score:4, Informative)

      by davegaramond (632107) on Sunday June 13, 2004 @04:06AM (#9412004)
      Before you cough on Ruby and said "2" + 2 in Ruby will equal 4, have you even tried it? Ruby (and Python) are _strongly-typed_ languages, unlike Perl (and PHP) which are weakly-typed. Ruby protects you from mixing string and numbers in operations like +. You'll have to say "2".to_i + 2.

      And having used all four of those for projects large and small, I can say with confidence that I prefer strongly typed language. Weakly typed language is more dangerous and error-prone.
  • by linuxbaby (124641) * on Saturday June 12, 2004 @11:08PM (#9410978)
    Anyone interested in the benefits of different programming languages should read some of the great well-thought-out essays by Paul Graham []:
  • by killjoe (766577) on Saturday June 12, 2004 @11:12PM (#9411002)
    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.
    • by OmniVector (569062) <see my homepage> on Sunday June 13, 2004 @12:28AM (#9411364) Homepage
      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.
  • by rolling_bits (754633) on Saturday June 12, 2004 @11:32PM (#9411130)
    Check out my site for some Ruby GUI stuff:
    (the gotcha is it's mostly in Portuguese. So jump to the "Exemplos Meus" (My Examples) section. Or use babelfish: []) []

    Hey, web stuff is easy with Ruby as well. But I don't have such examples for you. You have to get a taste of Ruby to find about its web capabilities. I Know IOWA has an example: []

    Further enlightening at: [] [] []

    You know, once you get addicted, there is no going back! :-)
  • Which Language? (Score:5, Insightful)

    by TastyWords (640141) on Saturday June 12, 2004 @11:42PM (#9411174)
    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)
    • Re:Which Language? (Score:3, Interesting)

      by dmaxwell (43234)
      I'd just go to the bad side and be done with it. I've coded some small things in php because we needed them and weren't going to get them any other way. I pretty much learned what html and SQL I know at the same time. I have no trouble admitting this because I'm an admin who occaisionally codes rather than the other way around.

      I've tried to avoid pulling obvious boners but I'm glad none of the machines running these things are exposed to the public net.
  • by rfc1394 (155777) <> on Saturday June 12, 2004 @11:56PM (#9411232) Homepage Journal
    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.

  • by Temporal (96070) on Sunday June 13, 2004 @12:05AM (#9411272) Journal
    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.
  • by Vector7 (2410) on Sunday June 13, 2004 @12:13AM (#9411307) Journal
    > 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).


    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..
  • So in summary, (Score:4, Insightful)

    by NorthWoodsman (606357) on Sunday June 13, 2004 @12:31AM (#9411379) Homepage
    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.
  • by bhurt (1081) on Sunday June 13, 2004 @12:31AM (#9411380) Homepage
    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.

  • by Tablizer (95088) on Sunday June 13, 2004 @12:33AM (#9411386) Journal
    In a similar vain, I wrote up a scripting language comparison document, but focused more on features rather than particular languages. Comparison Link []. I describe the various feature options, and then weigh the pro's and con's of each.

    After years of debating language features, I generally conclude that a lot of it is subjective. No language will ever satisfy everybody.
  • by SuperKendall (25149) * on Sunday June 13, 2004 @01:43AM (#9411650)
    WHy compare with Java when there is Groovy [], the JVM scripting language?

    Here's a simple sample script:

    #!/usr/bin/env groovy
    println("Hello world")
    for (a in this.args) {
    println("Argument: " + a)

    Note that you can run this from a command line, no compiling required.

    Groovy is not just some random basement project either, it's actually a JSR [] and so will probably become a standard before too long.

    If you want a C3 equivilent, I'm sure some well-meaning but mistaken soul will copy this project as they have tried to do with every other Java project. "C# - only a year behind Java since 2003!".
  • by soccerisgod (585710) on Sunday June 13, 2004 @03:27AM (#9411915)

    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.

  • Silly Java mistakes (Score:5, Interesting)

    by Decaff (42676) on Sunday June 13, 2004 @05:46AM (#9412233)
    There are some silly mistakes in this article, suggesting that the author does not really understand the languages he is comparing.

    Here are some examples:

    for 'return exit code error (non zero) if a file does not exist' and 'return exit code error (non zero) if a file is not readable. There is no Java or C# code supplied. Java can easily test this: for example

    new File(filePath).canRead();


    new File(filePath).exists();

    and I'm sure C# can as well.

    There are other omissions:
    Under Java 1.5, the System.getenv() method allows access to environment variables.

    Also, saying Java is completely unusable in a scripting environment is nonsense. The BeanShell system has been around for years, and allows java to be run as if it were a scripting language, both from a command prompt or from script files. Java 'scriptlets' on JSP web pages are very common. Finally, there is a PHP/Java interface.

    I don't know C# well, but I'm sure there are similar facilities for that language.

  • TCL Got shortchanged (Score:4, Informative)

    by EvilTwinSkippy (112490) <[yoda] [at] []> on Sunday June 13, 2004 @06:10AM (#9412283) Homepage Journal
    I was reading through the criteria, and TCL was docked points for not being able to pass commands through the command line and not having a debugger.

    Both are untrue. TCL will happily take command line arguments, and if you set the execute bit under unix, will happily act as programs. If by "programs can be passed over the command line" that he wants to bang out to the shell, there is the exec command. Of course in his hello world program he uses BOTH features.

    TCL gives you a complete stack dump on every error that is stored in a global variable "lastError", and you can override the background error with the bgError command. That also covers the "FullInterpreter in Debugger". The language was designed AS a debugger to C programs for christ's sake.

    All told that cost TCL 15 points.

    Sure I'm quibbling, but if you aren't going to compentantly seek out features save in all your favorites, you look like an idiot putting these comparisons together.

    (Disclosure: TCL Guru.)

  • by Qbertino (265505) on Sunday June 13, 2004 @07:20AM (#9412402)
    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.

Whenever a system becomes completely defined, some damn fool discovers something which either abolishes the system or expands it beyond recognition.