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."
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?
Generally, it's used to refer to a non-compiled, interpreted language that has some simple structure and has a set of discreet functions or environment objects that you can use to automate processes. Here's WikiPedia's definition, which isn't too bad.
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.
You're recalling the Osborne Effect. I sure hope that doesn't befall Perl.
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.
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
Clearly you haven't heard of Jaxer.
Three years ago, ctypes 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 seems like good coordination to me and easy_install psycopg2 and similar have never let me down.
Bogtha Bogtha Bogtha
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.
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"?
For such problems, Cython ( http://cython.org/ ) is really nice.
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.
how to invest, a novice's guide
Can Perl 6 access Perl 5 modules while in Perl 6 mode?
Yes, Perl 6 will be able to use Perl 5 packages.
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.
As Esther said, there are tons of languages I'd have loved to include, had allotted word count been infinite, but we finally decided to go with the ones we talked about last time, and only add JavaScript because Ajax is so prominent these days.
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
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.
I am anarch of all I survey.
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::
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).
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.
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.
import re
reg = re.compile('.*@')
m = reg.search(string)
print( m.group() )
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.
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.