Slashdot Mirror
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."
Hello, I am the Slashdot Source Code. The answer is Perl. This question is now answered.
Thank you for visiting Slashdot.
... for a difinitive answer to a subjective question.
where's php?
print "hello world";
/* oops I accidentally made a comment, sorry */
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.
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.)
...but it's being eaten...by some...Linux or something...
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.
WANNAWIKI Wannawiki WannaWiki WANNAWIKI!
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?
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.
The dangers of knowledge trigger emotional distress in human beings.
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.
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.
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...
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.
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.
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.
evil is as evil does
Most copies of PHP use the equivalent of mod_perl -- i.e. they cache the compilation. Use mod_perl, cache your compilations, and you will find performance is as good if not better than PHP.
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.
An interesting anagram of "BANACH TARSKI" is "BANACH TARSKI BANACH TARSKI"
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: http://babelfish.altavista.com)
http://geocities.com/canalruby
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:
http://enigo.com/projects/iowa/index.html
Further enlightening at:
http://www.ruby-doc.com
http://www.rubyforge.org
http://raa.ruby-lang.org
You know, once you get addicted, there is no going back!
It never was an acronym. See an explanation of Perl's name for an explanation of the backronym.
how to invest, a novice's guide
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)
now lets say i put Ruby on my resume....how 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.
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.
The lessons of history teach us - if they teach us anything - that nobody learns the lessons that history teaches us.
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...
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.
> Interesting that ICFP contests lately pronounced OCaml as the winner for rapid development.
.o absent, invoke grep on some files, etc).
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
[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..
Showing that you are self-motivated, and more interested in using the right tool than the "cool" tool, makes an impression
Java is the blue pill
Choose the red pill
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.
1p}{ 1 sp34k |33+ +|-|e|\| p30p13 \/\/il| 8e i/\/\pr3553|)
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.
Table-ized A.I.
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.
Are you adequate?
If you bothered to read the article...
The lines of code needed to achieve a task are measured, as they serve as an indicator on how fast one can create a script.
If you need 20 lines of C# to check if a file exists, but only one in Perl, then according to the study, Perl should receive a better weighted score for ease of implementation.
Read the articles people! They are interesting (at least most of the time).
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();
and
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.