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."
Re:What about a Comparison Matrix (Score:5, Informative)
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:
Major players? (Score:4, Informative)
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?
Re:Scripting language. What is it? (Score:2, Informative)
Re:future of perl? (Score:3, Informative)
Re:Major players? (Score:5, Informative)
That was a pretty reasonable guess, except it isn't correct. :-)
Lynn understandably went back to the same people, initially, since it would be easiest to say, "Hey, three years ago you said this... change you mind on anything?" Some of the guys didn't have the time (for example, Guido's a little busy with the next version of Python), so she asked who they'd recommend she speak with instead. To my understanding, Dave Thomas suggested Lam. Though he might have suggested someone else who suggested Lam.
IOW it had nothing to do with Microsoft. Though, come to think of it, it could be a good idea to ask all the Scripting Dudes and Dudettes from Microsoft for their opinions on stuff. Hmmmmmm.
Osborne (Score:5, Informative)
You're recalling the Osborne Effect [wikipedia.org]. I sure hope that doesn't befall Perl.
Re:Scripting language. What is it? (Score:2, Informative)
I think, judging by this list, is that a 'scripting language' is considered to be anything that can be/usually is run directly from the source code (for example, via a #!/usr/bin/interpreter under any Unix-like).
I'm not sure why JavaScript is on this list, by that definition, though. The rest are system scripting languages (best term I could come up with - i.e. sysadmins writing scripts), or server-side. JavaScript is web browser-only, client-side scripting.
Re:Glaring Omission: Groovy (Score:5, Informative)
It was a conscious omission... or perhaps semi-conscious. Lynn and I thought that if we were going to revisit the topic we should look at the same languages we did before.
I do want to cover Groovy at CIO.com, honest. Just haven't had a good hook for it yet. I feel like there's an opportunity for "&number; programming languages your developers wish you'd let them use" aimed at CIOs and IT managers, with Groovy probably top on the list. But I don't know what else ought to be on the list, so I haven't done anything with this idea. Suggestions always welcome.—Esther
Jaxer (Score:2, Informative)
Clearly you haven't heard of Jaxer [aptana.com].
Re:Things haven't improved much. (Score:4, Informative)
Three years ago, ctypes [python.org] wasn't part of the standard library. It is now, and it's great, not troublesome at all.
Can you give an example? The DB-API [python.org] seems like good coordination to me and easy_install psycopg2 and similar have never let me down.
Re:Things haven't improved much. (Score:5, Informative)
There's a Perl 6 effort, with a major language redesign, expected to ship shortly after Duke Nukem Forever.
Only someone who hasn't been paying attention would believe that. Perl 6, the language, is largely completely specified at this point. Meanwhile, Pugs has gone a long, long way to a working Perl 6 implementation, and the vast strides in Parrot mean Rakudo, the Perl6-on-Parrot implementation, has made immense progress in the last six months.
Does that means Perl 6 will be out this year? No. There's still plenty of work to do. But the idea that Perl 6 has anything at all in common with DNF (which, unlike Perl 6, has suffered from constantly changing specs, engines, etc) is incredibly insulting to all those who are working to make Perl 6 a reality.
Re:future of perl? (Score:5, Informative)
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.
Re:Good timing (Score:1, Informative)
Re:Things haven't improved much. (Score:3, Informative)
We also release a new version of Rakudo with the monthly stable release of Parrot, as we've done every month for the past 20 months.
Re:Osborne (Score:3, Informative)
I can't answer that directly, having never written VB.NET, but I've written Perl 5 code, Perl 6 code, and VB code, and Perl 6 is a tremendous improvement over Perl 5 in many ways. I say that admitting that I've written a lot of Perl 5 code and I like Perl 5. You should try Perl 6; it's very nice.
I don't believe any of the syntax changes are arbitrary; they're all documented with their motivations. Besides that, if Perl 6 is only as good as Perl 5 was, there's no reason to work on Perl 6. Again, having written code in both languages, I believe Perl 6 is much better than Perl 5 is, and will be more appropriate for many new types of problems. As well, Perl 5 has a VM too.
When one of the features of Perl 6 is grammar mutability (such that you can parse Perl 5 code) and one of the main implementations of Perl 6 is a VM that can run Perl 5 code as well as Perl 6 code, it seems silly to require people to rewrite all of their existing Perl 5 code at once before they can use any Perl 6 code.
Re:future of perl? (Score:4, Informative)
Can Perl 6 access Perl 5 modules while in Perl 6 mode?
Yes [programmersheaven.com], Perl 6 will be able to use Perl 5 packages.
Re:What about a Comparison Matrix (Score:2, Informative)
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///).
Re:Glaring Omission: Groovy (Score:3, Informative)
I contacted all of the guys from the original article, BTW, but some couldn't participate this time and suggested others who could speak for their language communities.
Lynn
Re:Scripting language. What is it? (Score:3, Informative)
Scripting languages are stored as text files, and are (mostly) compiled into some kind of intermediate or binary form *only at runtime*. Examples are Javascript and PHP.
Byte-code languages are stored in a platform-neutral ("virtual machine") binary code, and then this is interpreted - or else compiled into real machine code - at runtime. Examples are Java and ActionScript (in Adobe Flash).
Compiled languages are stored as real machine binary code, formatted according to the specific platform they were compiled for (e.g. ELF, PE, etc). Examples are C++ and Fortran.
Re:Things haven't improved much. (Score:3, Informative)
Perl 6 has made huge strides since 2000. The question is whether progress of the project will ever catch up with the goal posts.
Umm... the goalposts are set. The language spec is done. The test suite is being built. All that's left is to implement it, and that's being done as we speak. What else do you want?
After eight years, the best you can say about the language specification is that it's "largely" complete?
Last I checked, the C language spec was still being worked on. And yet, C compilers abound. So what's your point? The vast majority of the Perl 6 language is done. Period. As I understand it, there are a few places where work is still being done, but implementations can, and are, building on the existing spec, because it's *finished*.
Besides, you took one small quote and asked "is that best best you can say?". Funny how you completely ignored the rest, such as the test suite, and the two ongoing implementations. But, I guess if you want to be an alarmist cynic, the best way is to distort the discussion to your advantage.
Perl 6 is a much bigger disaster than DNF.
Umm... why? Perl 5 continues to exist, the implementation continues to evolve (eg, Unicode support didn't exist in the original Perl 5), so who cares if Perl 6 takes a bit of time?
Perl 6 keeps siphoning off mindshare and developers.
Uhh... okay. I can't say I've seen that, but if you say it's true, I guess it must be... despite the fact that you contradict yourself in the very same sentence, pointing out, as I already have, that Perl 5 continues to move forward.
Parrot threatened to throw other scripting languages into a similar state of confusion
Because it'll provide a new platform to target, much like the .NET CLR or the JVM? Yes, I can see how that's such a terrible disaster. I know when the CLR came out, the scripting world was thrown into a state of chaos... ::rollseyes::
Re:What about Lua? (Score:3, Informative)
That's really a product of it's market. Lua has made it's name by being a light-weight, easily embeddable interpreter. The consequence is that no one really uses it for truly general-purpose programming (unlike the other languages in the list). That's not to say Lua couldn't be used for such a purpose, it's just that no one really bothers (at least, AFAIK, I could be wrong).
Re:future of perl? (Score:3, Informative)
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.
Re:Caught in a crossfire (Score:5, Informative)
The primary flaws in javascript are its lack of namespaces, true OO, and, most of all, its lack of types and type safety.
The primary flaws in javascript are developers that do not understand the fundamentals of the JS language (and I don't mean to be attacking anyone particular, this is just a really common problem).
JS is 100% Object Oriented. Just because it contains Functions as first class objects and Closures does not mean it is not Object Oriented. Everything in JS is and object, everything. There are no classes because it's a prototypical system not a classical system. The fact that all things are objects and that JS contains closures means that Namespacing does exist, if you have some specific reason to use, just by creating an object to represent the name space and keep all namespace protected objects in that objects scope.
Also JS is completely type safe. You can not cast an object to a type that it is not (something you can do in none type safe languages like C). What you meant to say is Strongly Static typed, which is found in only a few languages and is a huge hinderance in those languages. Duck Typing, as implemented in JS and few other languages, is far more flexible and just as robust as you still can't screw with memory arbitrarily.
The only thing I would give you is that it would be interesting if JS variables could be typed (as the objects already are). This would allow the runtime environment to determine type conflicts and for an IDE to be able to have additional autocompletion options. But sadly this would just lead to other problems just as difficult.
Re:future of perl? (Score:1, Informative)
import re
reg = re.compile('.*@')
m = reg.search(string)
print( m.group() )
Re:Glaring Omission: Groovy (Score:4, Informative)
The original title was "State of the Scripting Universe Revisited." It was too long for the ./ subject line. And the CIO.com one had to be written for search engines as well as humans (for reasons that are probably obvious but annoying nonetheless).
Still, the article's deck does say that it's a follow-up. As you'll see elsewhere in this thread, I'm happy to write about Groovy et al.
Re:All of this was done in LISP in the 70s (Score:1, Informative)
As a matter of fact, the PyPy implementation of Python is working on a LLVM-based just-in-time compiler backend. Here's to hoping they'll get mainstream before the end of the decade.