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:Caught in a crossfire (Score:5, Insightful)
I am getting more comfortable with Javascript, though I still think DHTML and CSS are fundamentally fucked, and it really is time, if this web delivery of apps thing is for real, to find some more rational means of actually dealing with dynamic content.
Syntax argument. (Score:3, Insightful)
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.
Re:Scripting language. What is it? (Score:2, Insightful)
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".
If it started out as a compiled programming language then it's not a scripting language.
Scripting languages are for moving files around, administrative tasks and doing odd jobs.
At least that's what it was in my day when we had to program in the snow uphill both ways and liked it!
Re:future of perl? (Score:4, Insightful)
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.
Re:Syntax argument. (Score:5, Insightful)
This sounds like a comment from twenty years ago. These days, with fast hardware and lots of memory, for a great many purposes making things easier and faster for the programmer is the most important goal.
Scripting languages also differ in more than syntax. They differ in the set of primitives and available library functions and in the efficiency of implementation of different components.
quality and libraries, but quality of libraries? (Score:5, Insightful)
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.
Re:Scripting language. What is it? (Score:5, Insightful)
Agreed, as Python, Ruby, etc. are compiled to byte code which run on virtual machines, just like Java...yet no one calls Java a scripting language. So I'm not sure either. Maybe it's "dynamically typed and either interpreted or runs on a virtual machine"?
To be honest, Bash is one of the few 100% interpreted languages I know, and the only one I call a scripting language these days.
Re:What about a Comparison Matrix (Score:5, Insightful)
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.
Re:Caught in a crossfire (Score:3, Insightful)
Re:Syntax argument. (Score:3, Insightful)
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.
Sure! So Python and COBOL are exactly equivalent and there's no real reason you'd pick one over the other.
You know, there's more to a language than Turing completeness.
Re:Syntax argument. (Score:1, Insightful)
Productivity metrics keep showing that a line of code is a line of code. If you can write the same program in language X in 1000 LOC and language Y takes 2000, then you will be finished with language X program much sooner and have fewer bugs.
Perl, PHP, and the other languages discussed here are essentially interchangeable, but each is a big improvement over C++ or Java, in terms of verbosity. Therefore, that's what the CIOs care about.
Another Perspective on Dynamic Languages (Score:4, Insightful)
Re:Osborne (Score:5, Insightful)
I do not understand all that stuff surrounding Perl 6.
Perl 5 is near perfect: it does many things very efficiently, especially in coding effort department.
Perl 6 is different beast. Perl 6 is a standard. Whatever implements standard can be called Perl 6. There are several implementations underway (mostly complete by now) but they are pretty much unknown to masses due to huge popularity of Perl 5.
All this talks about Perl death remind me the talks about assembler programming death. My groupmate told me that in University about decade ago. Since then, like a curse, I have to deal with assembler regularly. Not that I have anything against it. But it bothers me that some people when see something new, fancy and shiny and quickly declare everything else old, uncool and boring.
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.
All of this was done in LISP in the 70s (Score:3, Insightful)
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*
Re:Caught in a crossfire (Score:3, Insightful)
Or write CSS-compliant browsers. Nobody implements CSS fully.
Incrementing filenames... (Score:3, Insightful)
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"...
Re:future of perl? (Score:5, Insightful)
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?
Re:Scripting language. What is it? (Score:3, Insightful)
One good reason Java isn't a scripting language: it's impossible to write a script in it:-)
What about Lua? (Score:2, Insightful)
Poor Lua never gets the respect it deserves.
Re:Syntax argument. (Score:2, Insightful)
Secondly, this article is in CIO. WTF does a CIO have to worry about languages for? That's the development manager's problem.
OK. So just throwing out a wild guess: You're not a CIO, right?
Look, if the code is doing anything in production, the CIO better have some idea of what it's written in and have some sort of an opinion on that. It is very much a strategic issue. Caring about those details (yes, without getting mired in them) is what a CIO should be doing.
But, maybe we're thinking the same thing but in different environments. I'm thinking mid-sized companies, maybe you're thinking much bigger. As the organization gets bigger, sure the CIO can't have his fingers in everything.
Re:Syntax argument. (Score:3, Insightful)
But, anyone who's proficient in any language can be just as productive as another programmer whose just as proficient in another language.
Really? If you have two programmers who both have the whole program perfectly in their heads, the programmer writing in a language that requires fewer keystrokes win.
Re:Things haven't improved much. (Score:2, Insightful)
Would you care to give a list of name of people that group isn't? I can give you a list of names that group is. I'm curious if you've paid enough attention to cross off every name on my list.
Re:future of perl? (Score:3, Insightful)
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?)
Re:future of perl? (Score:3, Insightful)
"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.
Re:Major players? (Score:3, Insightful)
I'd be extremely surprised if Dave Thomas had recommended John Lam as a prime representative of the Ruby community - he has lots of authoritative Rubyists as authors at his publishing company.
Re:Caught in a crossfire (Score:4, Insightful)
Wow, that's a pretty extreme point of view. Static typing may be "found in only a few languages" but those languages happen to be the most popular languages by far. Just because every man and his dog has written an interpreted language without static type checking doesn't mean it's somehow a small irrelevant feature. In fact as code bases become larger it becomes nearly essential. I don't see how you can claim it's a "huge hindrance" - you sound like something of a cowboy programmer to be honest. Defining and declaring your types up front may seem inconvenient but it means your codebase can scale, more bugs are found ahead of time, future programmers can more easily comprehend your code and compilers can optimize your code much more easily.
If there was some kind of efficient, statically typed language available for use in web browsers making it run fast wouldn't be a research problem, and we could replace the unintuitive CSS box model with something that actually worked for web apps. The reason you can't do this today is that JavaScript is just too damn slow to do real time GUI reflow, so you have to let the web browser do it in C++, so you're stuck with CSS.
The OP doesn't have to wait for SilverLight to get the benefits of static typing however. GWT does the exact same thing today, for Java.