Slashdot Mirror
The State of Scripting Languages
Esther Schindler writes to tell us that Lynn Greiner has another look at the state of the scripting universe as a follow on to the same topic three years ago. Greiner talks to major players from each of the main scripting languages (PHP, Perl, Tcl, Python, Ruby, and Javascript) to find out the current status and where they are headed in the future. "The biggest change since 2005 has been the growth of richer Web applications that perform more of their computations in the browser using JavaScript. The demand for these applications has forced developers to learn and use JavaScript much more than before. There's also been a lot of interest in Ruby, another dynamic language, spurred by the release and growth of Ruby on Rails. As a result of these changes, many developers are becoming more comfortable with dynamic languages."
Preemptive strike! You're a moron, and Java != Javascript!
schindler's list looks neat. I'll go read it sometime.
Show this to your friends and family that don't know what a real hacker is
Nah, I'm not really caught in a crossfire. I still prefer my trusty old Perl over these illegitimate kids and cousins - PHP, Ruby, Python, etc etc.
slashdot rocks
Language | Turing Complete?
PHP | yes
Perl | yes
Tcl | yes
Python | yes
Ruby | yes
Javascript | yes
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
Can anyone come up with a really good definition of a "scripting language"?
As far as I can tell, it's a vaguly amorphous definition based on some notion of interpretedness, but C interpreters exist, for instance, and TCC can be used to run C "scripts".
SJW n. One who posts facts.
Language | Has a "p" in it's name
PHP | yes
Perl | yes
Tcl | no
Python | yes
Ruby | no
Javascript | yes
First of all, it was an argument about scripting languages - the only difference is syntax. Yeah, yeah, one language make it easier for the programmer to manipulate text or to develop some functionality for a particular task. But this jazz of "the right tool for the right job" is non-sense. We're talking about programming languages: not screwdrivers, drills and hammers. It's all going to be a processor's instruction set one way or another.
Secondly, this article is in CIO. WTF does a CIO have to worry about languages for? That's the development manager's problem. The CIO's problem is the management of the organization and the technology big picture. How said technology is implemented isn't his problem: that's just minor details. I guess a micro manger would be concerned about a scripting language. If that's the case, he needs to quit and get a tech management job.
Just my two cents.
Note: I only know PHP and Ruby.
Learn javascript. It's by far the most valuable language on that list if you already know PHP and IMHO, the most fun regardless.
Pros:
Cons:
John Lam leads the IronRuby team at Microsoft.
Okay, John Lam is doing amazing work and IronRuby will likely be of some importance in the Ruby world one day, but "major player"? Microsoft's a major player generally, but in the Ruby world they are not. There are 1001 more notable people in the Ruby community who probably would have been up for this article - Chad Fowler, Dave Thomas, David Heinemeier Hansson, Matz himself.. They seem to have picked senior figures for all of the other languages (except PHP). CIO.com is not that poorly connected, surely?
Maybe someone needs to look up the word "Preemptive"?
The United States of America: We do what we must because we can.
Sorta. Was it Sinclair who announced how great their next computers would be, to the point that no one would buy their current offerings? I think Perl's going down that route, and the longer it takes, the fewer programmers there will be to try it when it comes available. I'm not a Perl hater by any means, but I jumped ship for Python a long time ago. I think most Perl hackers have done the same, or picked up Ruby. Perl 6 always sounded interesting, but not so much that I'd put up with Perl 5 until it was ready.
Dewey, what part of this looks like authorities should be involved?
This essentially summarizes the reasons I prefer to use Perl: the quality of the implementation, and the good libraries. However, there is a dark side that we Perl lovers don't talk about much, which is that although Perl has good quality and good libraries, many of the libraries are not of good quality. My purpose here isn't to name names and rip into individuals who have contributed open-source code to CPAN out of the goodness of their hearts, but honestly, some of the code on CPAN is of very low quality and/or very poorly maintained. Quite a few CPAN libraries are basically glue that interfaces to some C code, and when you look at some of that C code, it looks like examples of the worst coding practices of the 1980's, before the internet existed, and before it really registered on coders' consciousnesses that buffer overflows, etc., were not just bugs but security holes. I've had a couple of bad experiences where I hitched my wagon to a particular CPAN module, and later had serious problems because that module was not actively maintained. E.g., crippling bugs would go unfixed for a year at a time.
On the other hand, I'm not sure that any of the other scripting languages come off any better. What the article says really is true: the base implementations of the other scripting languages are really not anywhere near as solid as Perl's is -- probably partly because Perl is so much older than the others, and therefore more mature. But this may change a lot in the future. Perl 6 is eventually going to be ready for prime time, and there will be a certain amount of chaos and confusion and bugginess at that point, as everyone adapts to the new environment. Also, Perl's head-start in terms of maturity will start to mean less and less as time goes on and the other scripting languages start to get more mature.
Find free books.
PHP | Annoying fanbois
Perl | Annoying fanbois
Tcl | No fanbois
Python | Annoying fanbois
Ruby | Annoying fanbois
Javascript | Annoying fanbois
* | rand()%2?"Annoying fanbois":"No fanbois"
Actually, I think one can draw more useful conclusions about fanbois than languages. How about something more concete.
Advantages:
PHP | It's not perl, tcl python, ruby or Javascript
Perl| It's not PHP, Tcl, Python, Ruby or Javascript
Tcl | It's not PHP, perl, Python, Ruby or Javascript
Python| It's not PHP, perl, Tcl, Ruby or Javascript
Ruby| It's not PHP, perl, Tcl, Python or Javascript
Javascript | It's not PHP, perl, Tcl, Python or Ruby
Funnily enough the disadvantages are *exactly* the same.
SJW n. One who posts facts.
TCL is very strongly typed. Everythin is a string. That's a 100% unbreakable typesystem :-)
SJW n. One who posts facts.
One that is complete, impartial and fair? You won't find it. Each language has it's strengths. Some have larger libraries, have been better tested, are geared towards system administrators or the web, some scale better than others, etc.
You would be asking for a flame war to list which is which but each has proven itself in it's own community. Usually, age, adoption, libraries and (mature)user applications is what makes the language mature and get better. Find those and you will find a decent language.
This is my sig. There are many like it but this one is mine.
They all still suck for about the same reasons they sucked three years ago.
The problems of Perl are well known, but it's probably the closest thing to "write once, run everywhere" that we have. Perl is essentially static at Perl 5. There's a Perl 6 effort, with a major language redesign, expected to ship shortly after Duke Nukem Forever.
PHP is gaining because it's a simple way to do dynamic web site back ends. It's not a great language, and limited to its niche, but useful there.
TCL was never a very good programming language, and it hasn't improved much.
Python is a nice language, but it still suffers from the limitations of the CPython implementation. It's slow, and integration with standard C modules is troublesome. Python has distro packaging problems - the Python maintainers don't coordinate with the maintainers of key modules, like the ones for talking to databases, and as a result Linux distros don't consistently ship with a CPython and a set of modules that play well together. That's why Python hasn't replaced Perl.
Javascript is a moderately painful language, yet we all have to use it. The object model is ill-designed; borrowing from Self was a mistake. Too much use is made of "eval", creating the "JSON" security hole. (Memo to language designers: don't combine the primitives for reading a string into an internal representation and for executing the internal representation. LISP has the "reader" and "eval"; Javascript has one function that does both.) Variable scope, given that the language has "var", is badly thought out. (Python is one of the few languages that does implicit declarations well. Perl had to retrofit "my", and Javascript had to retrofit "var", and in both cases, implicit declarations stayed, confusing the issue.) Because of this, Javascript has scaling problems. Attempts are made to paper this over with "toolkits", usually a bad sign.
I can't really say much about Ruby.
It's interesting that nobody uses Java applets much any more. It's worth understanding why that failed. But that's another subject.
What did they use to code the Matrix?
Pffft, Perl is perfectly good for anything that needs string manipulation and such. You shouldn't ignore new languages that come along, but neither should you ignore old ones that get the job done perfectly well.
It is pitch black. You are likely to be eaten by a grue.
I hear a lot about Ruby performance - specifically, "Ruby/Rails can't scale". The odd thing is that this is in the context of a web app, where the overhead of the interpreter opcode execution is dwarfed by the cost of going over a socket to pull data across a LAN from a database. Scaling a web app isn't about the language; it's about architecture, judicious SQL optimizations, and caching.
Oh, and if you're using rcov to measure your Rails app's code coverage, try this patch to prevent rcov segfaults. It doesn't fix the root problem, but it's a start.
The Army reading list
I was surprised that Groovy didn't appear anywhere in the article. If there's a dynamic language poised to convert the enterprise crowd, its Groovy. Able to compile into Java bytecode, compile Java code, and directly exploit the huge base of Java, but without the cumbersome Java syntax. I wouldn't be surprised to see Python and Ruby supplanted by Groovy in a couple of years.
007: "Who are you?"
Pussy: "My name is Pussy Galore."
007: "I must be dreaming..."
Python has been my language for years. The pure beauty of the language together with the huge library did it for me. Plus, it's very easy to program python. Seriously. Just today, I've implemented an algorithm with a long, long loop and a lot of arithmetic operations. Python took 5:30 where Java took 10 secs. I'm serious, Python is SLOW, and last time I've checked, Ruby is even worse. (Interesting sidenote: C++ took 11 secs). I seriously love scipting languages, but the speed it horrifying. I'll stick to Java for a while.
You're recalling the Osborne Effect. I sure hope that doesn't befall Perl.
Pffft, Perl is perfectly good for anything that needs string manipulation and such.
Unfortunately for Perl, so is Python.
(Well, and Ruby. I'm partial to Ruby, but there's no XKCD for me to link to.)
Don't thank God, thank a doctor!
Clearly you haven't heard of Jaxer.
Javascript | yes
Are you really sure?
Swedish plasma phys. PhD student; MSc EE; knows maths, programming, electronics; finance interest; seeks opportunities
Ruby's going through its own somewhat painful transition right now, what with 1.8.7 and 1.9. Hopefully that'll work itself out fairly soon, though.
I really like DHTML + JS + CSS for dynamic content. I downright love CSS; it takes time to learn, but it is just awsome. It's really just a problem of getting browser vendors to support a cross-platform standard for the DOM tree (I think we all know who I am talking about). Even with the mess that we have now, js libraries like prototype.js and mochikit have done a pretty good job of abstracting the browser quirks out of our code and given us a means to develop quality, working web applications quickly and easily.
Or, you could scrap all this progress and start over on a new standard. Good luck with that.
weirdest thing I ever saw: scientology advertising on slashdot.
Dynamic Languages Jobs Barometer
007: "Who are you?"
Pussy: "My name is Pussy Galore."
007: "I must be dreaming..."
Perl is a language for getting work done in. Plain and simple. It's not as cool and trendy as Python or Ruby, but it is more mature and IMHO more productive.
The "write only" complaint of Perl is easily addressed by adhering to some basic coding standards and (gasp!) commenting your code. A little self-discipline goes a long way.
I work with 4 other Perl programmers. Because we all follow a simple set of coding standards and design patterns, no one has any problems understanding anyone else's code.
Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
I prefer Perl's way of doing it:
my ($i,$j) = (1,2);
print $i + $j; # = 3
print $i . $j; # = 12
If you your string concatenation operator is distinct from your addition operator, it's simple to tell whether you are dealing with a string or a number from context. Plus it lets you do neat stuff like:
my $filename = 'file0000';
$filename++; # = file0001
Why write more code than you have to? Unnecessary complexity makes your code harder to write, harder to maintain, and harder to understand.
Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
P.S. And, btw, ask the .Net crowd about scripting languages. M$ already brainwashed them. Will you see, C# is not scripting, CLR is not interpreter. Scripts sucks because they sucks and C# is better. Scripting languages are dead. End of topic. Move on.
Really? Is that what the culture's like? I am not really a part of that so I don't know... My impression was that .NET had a lot to offer for users of Unix scripting languages - really good interaction with other languages and applications' scripting interfaces, good bindings to system facilities, and the ability to take advantage of the CLR for just-in-time compilation...
Bow-ties are cool.
It's amazing how much people forget. 'dynamic languages are gaining acceptance' - some of the first programming languages were dynamic. Almost all of the 'innovations' we have seen in 'scripting' languages in the past ... 20 years or so have been done before, in LISP, normally in the 70s.
*sigh*
If you your string concatenation operator is distinct from your addition operator, it's simple to tell whether you are dealing with a string or a number from context. Plus it lets you do neat stuff like:
my $filename = 'file0000';
$filename++; # = file0001
Why write more code than you have to?
And if you have more than 10000 files? Not to worry, your filename will advance from "file9999" to "filf0000" - the counter system is naturally extensible... ...There's something to be said for telling the language exactly what you want it to do, rather than trusting that the default behavior, whatever it may be, will do what you want... especially when you're dealing with a funky concept like "incrementing text"...
Bow-ties are cool.
but I jumped ship for Python a long time ago. I think most Perl hackers have done the same, or picked up Ruby.
I really don't get it. I know Perl inside and outside. Last year I learned Python, and currently I'm reading a book on Ruby. But that doesn't make me forget Perl, so why not use it when it fits the problem being solved. Additional languages are new tools to add to your toolbox, but they don't remove your old tools. Why stick with one language when you can use all of them as you see fit?
An often overlooked scripting language is Mumps (Massachusetts General Hospital Utility Multi-Programming System), developed in the late 1960's.
Mumps (also referred to as M) supports a multidimensional and hierarchical database facility implemented as string subscripted array references. It was widely used in clinical computing and remains to this day the basis of the U.S. Veterans Administration's computerized medical record system, the largest of its kind in the world.
Its main features are: (1) its tree-structured (multi-dimensional) database; and (2) its flexible string handling facilities which now including PCRE functions.
There are both compiler and interpreter versions available as open source/GPL packages. It supports many text processing functions, system shell integration, as well relational database access. There is also a compatible C++ library to integrate the tree structured data base access into C++ programs. The Mumps/II native hierarchical array database may range in size up to 256 terabytes.
The package is available from:
http://www.cs.uni.edu/~okane
(see download link).
Kevin O'Kane http://www.cs.uni.edu/~okane/
Java?
Going for a +5 funny IC.
I did so because Python is a complete superset of Perl for me. Anything I'd previously wanted to do in Perl, I can more easily do in Python. I guess that I can't think of a problem where Perl would be the best solution anymore.
Dewey, what part of this looks like authorities should be involved?
Ruby's going through its own somewhat painful transition right now, what with 1.8.7 and 1.9. Hopefully that'll work itself out fairly soon, though.
The difference is, 1.8.6 doesn't suck. Most of the difference is that 1.8.6 is slower, due to being on a slower VM. Most of what breaks (now, anyway) in the transition to 1.9 are various native extensions.
However, Perl5 does suck, compared to Ruby or Python. Perl6 looks very, very good -- but is nowhere near ready.
I could reasonably expect to pick up Ruby 1.8.6 (or 1.8.7), and have most of my existing code and coding style still work in 1.9. Or I could pick up 1.9, and backport some features to 1.8.6 (which is what 1.8.7 is, mostly).
I don't think I could reasonably expect to pick up Perl5, and know anything at all about Perl6. The best I could hope for is that most of my old code would still work in Ponie, which is Perl5 on the Perl6 engine -- implying that yes, they are completely different languages.
Don't thank God, thank a doctor!
Can Perl 6 access Perl 5 modules while in Perl 6 mode?
Yes, Perl 6 will be able to use Perl 5 packages.
Lua's said to be the number 1 scripting language for making games. Surely it deserves a mention.
Poor Lua never gets the respect it deserves.
line = re.compile('old').sub('new',line) is equivalent to line=re.sub('old','new',line). (I don't think that the compile is your only gripe, but the second version is quite a bit closer to the perl)
I would argue that the "=~" operator is only briefer than the equivalent python code, it isn't really any clearer (another difference is that the re.sub gives someone who isn't familiar with s/// something to search for; but that isn't something that matters a whole lot, it only happens once that a reader doesn't know s///).
Nerd rage is the funniest rage.
Tcl and Ruby have a p in their name, but the p is silent... as in swimming.
So, no interview with Mike Cowlishaw, the developer of Rexx? Ignoring Rexx, Object Rexx and NetRexx?
I thought this was about scripting languages.
And NASA alone having MILLIONS of lines of Rexx code.
I've coded Rexx on IBM CP/CMS, Amiga, and Linux.
And the Amiga version is better than what is available for Linux.
Rexx; everything is a string, and math is decimal based, with 15 digits of precision.
Yeah? So what?
In Javascript everything is a var.
So it is strongly typed too.
I am anarch of all I survey.
This part from the old TFA cought my eye:
When reading this, I immediately thought of ARexx (and now also show my fondness of the Amiga and somewhat show my age, now git of my lawn!). The use of scripting languages as glue between different programs is somewhat forgotten these days I think. Also forgotten is the easy witch with you could embed ARexx, and how extremely easy it was to interface with programs using ARexx.
I think these aspects could be better developed.
/ The Arrow
"How lovely you are. So lovely in my straightjacket..." - Nny
Pffft, Perl is perfectly good for anything that needs string manipulation and such.
Unfortunately for Perl, so is Python.
I think string manipulation is an area where I've found that Python just doesn't compare to perl or ruby. It is so much more annoying to write this in python: /(.*)@/) { print $1; }
if ($str =~
And no, I'm not afraid to write three more lines of code, but I hate moving logic away from the place where it's applied, just to support the limitations of a language.
A cat can't teach a dog to bark.
Why was the above marked "offtopic", or is Perl somehow not considered a scripting language, and is Perl-6 somehow not giving similar-flavor 'warm-fuzzies' as Vista?
Perl6 != Perl, Larry admits this -- he just took the perl name for recognition, but it's a new language.
The question is -- will the community of perl5 users just let perl die?
At least with Perl, there is an option. With XP vs. Vista, ... well, there *should* be an option, but...
You can create your own table with whatever weightings you want at the language shootout page: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all
Note that I linked the Gentoo/P4 platform since it has the most ranked entries.
Perl 5 is a glue, perl 6 will be a super glue. Perl 6 can glue together much wider range of codes, which of course, including perl 5.
I love the fact that Perl fans always mention regexes but never mention the fact that in a subroutine you have to unpack your own parameters with the really so blindingly obvious '@_' .
Now I don't know about you but most of the things I write in Python are pretty damn big and regexes are a very small part compared to say *all the functions*
So can I live with slightly more complex regex *syntax* in return for the rest of the language having a syntax I don't need to think about?
(and yes there are perl dudes who know this stuff inside out - but *why* would a newcomer scale these ridiculous barriers to entry?)
"Why stick with one language when you can use all of them as you see fit?"
Because there are only so many API's that fit into my tiny head.
I guess that I can't think of a problem where Perl would be the best solution anymore.
Any task that involves iterating over a bunch of lines, applying pattern matching to them. Perl is well optimized for this, and handles it substantially better than python. Although it's worth considering whether either sed or awk might be better -- they often are.