The State of Scripting Languages 415
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."
Caught in a crossfire (Score:3, Interesting)
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.
Scripting language. What is it? (Score:5, Interesting)
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".
Things haven't improved much. (Score:5, Interesting)
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.
Scripting language performance (Score:3, Interesting)
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 [blogs.com] to prevent rcov segfaults. It doesn't fix the root problem, but it's a start.
Glaring Omission: Groovy (Score:5, Interesting)
Good timing (Score:2, Interesting)
Re:future of perl? (Score:3, Interesting)
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.
Re:Scripting language. What is it? (Score:2, Interesting)
How about Firefox? Thunderbird?
I have; Microsoft had something which did this several years ago.
It's really just a problem... (Score:4, Interesting)
Or, you could scrap all this progress and start over on a new standard. Good luck with that.
Re:Scripting language. What is it? (Score:5, Interesting)
python - an interpreted, interactive, object-oriented programming language
ruby - Interpreted object-oriented scripting language
java - Java interpreter
First of all, ruby's man page calls itself a scripting language, and secondly...
#!/usr/bin/java
println("Hello World!");
Oh right...
You can call all of these "interpreted" languages, but the ones with interactive prompts, or able to execute a source input file I throw at it, those are scripting languages. Java is nowhere NEAR a scripting language, it was not built for this. The other languages WERE built for this. It's an important distinction, and it doesn't make a perl/python/ruby developer any less of a man. Honestly, the interactive portion, and executing with #!/usr/bin/foo are the #1 and #2 indicators that it qualifies as "scripting".
You almost sound like "scripting language" is derogatory. Well, it's not.
Many people WANT scripting functionality for the Java platform, but it isn't here until I can run a one liner from the command line.
Re:What about a Comparison Matrix (Score:3, Interesting)
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.
Scripting on .NET (Score:3, Interesting)
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...
Mumps - an often overlooked scripting language (Score:2, Interesting)
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).
Re:future of perl? (Score:4, Interesting)
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.
Re:future of perl? (Score:4, Interesting)
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.
Re:Osborne (Score:4, Interesting)
Perl 5 is near perfect: it does many things very efficiently, especially in coding effort department.
As a former Perl hacker who's been converted to Ruby, I must politely disagree. Perl5 is nowhere near perfect.
Perl 6 is a standard. Whatever implements standard can be called Perl 6.
Since that's "nothing", so far, it's pretty much vaporware.
CLR is not interpreter.
Again, in short: Yes, CLR is an interpreter. At least, it's every bit as much an interpreter as Perl is -- and every bit as much an interpreter as the JVM is.
There's another important difference: I can run Ruby and Python on .NET, and on the JVM. I can't run them on Parrot, which was supposed to be the one scripting VM to rule them all.
Re:Caught in a crossfire (Score:4, Interesting)
I also agree with you on the Javascript side of things. I'm a professional web developer, and I'm writing very complicated applications these days that use almost no postbacks, doing everything in the browser with javascript. It's necessary for performance reasons a lot of times, but developing in javascript is slow and tedious.
The primary flaws in javascript are its lack of namespaces, true OO, and, most of all, its lack of types and type safety. The types alone cause no end of headaches, because the compiler can't easilly find errors before runtime. We're back to the days of running the code, getting a disaster, and then trying to hunt through to figure out what went wrong. Additionally, it is impossible to have full intellisense in such language, so you have to remember large parts of the library, and even if you get pretty good at that (which I have), you still have to constantly go through javascript reference books as you code trying to remember the name of that one function you want to use and can't remember at the moment...
You are right, and such a way has appeared. It is silverlight 2.0. Now those of us who program in .Net can easilly use the .Net framework on the client and the server, and use the same (typesafe!) languages in both locations as well. Silverlight 2 is in beta but should be out by the end of the year, and as soon as it is, I quit javascript. I've trained and used the Silverlight beta already, and within an hour of it I vowed I wouldn't go back to the way things were.
Note: There are still some advantages to DHTML, assuming browsers are standards compliant. Then you don't have to worry about actually drawing animations on the screen... you just go through the DOM, add or remove some elements, change some css here or there, and the browser handles all the drawing for you. I might have stuck with DHTML had the new version of ECMAScript (the official name of Javascript) actually passed, since it was going to have features like namespaces, true OO, etc. But it was foolishly killed, and with that I leave. I wouldn't be suprised if vast portions of the web migrate away from HTML over the next 10 years because of that. And the glacial slowness at moving to XHTML 2 doesn't help either. It's gotten so bad vendors are trying to start an HTML 5 in the meantime, and I'm not going back to a DOM not based on XML, either. I refuse to be stuck in the past with all the problems of the HTML line.
Ignoring the 800 pound gorilla... (Score:2, Interesting)
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.
Script languages as glue (Score:5, Interesting)
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.
Re:future of perl? (Score:3, Interesting)
Pffft, Perl is perfectly good for anything that needs string manipulation and such.
Unfortunately for Perl, so is Python. [xkcd.com]
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.
Re:future of perl? (Score:3, Interesting)
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...
Re:Caught in a crossfire (Score:3, Interesting)
I think CSS has been stretched a fair bit farther than it ever should have been. It's not a layout language-- primarily, it's a text style description language-- but in the absence of anything better, we just have to keep on trying to figure out how to wedge the float mechanism into giving a decent multi-column layout (unless you want to play pixel-perfect with absolute positioning).
That, and I'd have to say-- and I'm someone who works in CSS every day-- parts of the box model would probably qualify as "fundamentally fucked". I hate to say it, but the flawed IE box model, where fundamental dimension declarations (width/height) include margin/padding/borders, makes a whole lot more sense and involves a whole lot less manual math when you're trying to align disparate parts together.
Re:What about a Comparison Matrix (Score:2, Interesting)
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 [debian.org]
Note that I linked the Gentoo/P4 platform since it has the most ranked entries.
Re:Schindler's List? (Score:1, Interesting)
Why is this BS modded funny?
Re:future of perl? (Score:4, Interesting)
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.
Re:Caught in a crossfire (Score:3, Interesting)
Some designs are hard to implement in CSS. Most aren't. The whole "holy grail" multi column layout thing *is* lame. It's not that hard. Just use some negative margins, floats, and one IE min-width hack and you're done.
I think that many, not all, people who don't like CSS are more used to developing fat client apps. There's nothing wrong with that. Designing for the web is much different, you first have to grok the concept of fluid layouts. If you came from an environment of "put this widget at x and y" then, yes, this is harder.
You could justifiably say that you shouldn't have to work so hard to design a layout. Fair enough, laying out some designs requires some clever CSS footwork. But that's where experience comes in.
Maybe you've used CSS quite extensively. In my past experience (and I have been a professional web developer for many years now) when people complain about CSS being no good, it's only because they don't know how to do what they want to do. Maybe that's not you, I dunno.
Oh, and while I see your point about how CSS is too kludgy, don't misplace the blame on the CSS spec. There is really only one browser anymore that doesn't adhere reasonably well to the spec. And that company also doesn't adhere to HTML specs, or many others. It took them ten years just to understand alpha-blended pngs. It's not the specs, it's the software company that shall remain nameless.