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."
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
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.
The world's burning. Moped Jesus spotted on I50. Details at 11.
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
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:
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.
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.
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..."
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.
You're recalling the Osborne Effect. I sure hope that doesn't befall Perl.
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"?
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?
but in the Ruby world they are not
Of course they aren't. Ruby is for fashion programmers with iMacs, iTunes and iPhones. Ruby is for programmers who moonlight as bar tenders. Ruby is for companies with numbers in their name. Ruby is for minimalists who eschew corporate wisdom. Ruby is for those who use words like eschew.
Ruby is hip. It is edgy. If you went into a bar and said "I use Ruby", you would get first game on the pool table. If you use Ruby, people call you by your initials, not your name.
You dont use Ruby to just get work done. No sir. You use Ruby to make a statement about who you are.
CF, DT, DHH and M himself are all cool beyond belief. They are the superstar hipsters of our modern programming world. C programmers, Java programmers and .NET programmers could never be as cool as DHH--not even on the best day of their lives.
Go home you Microsoft Player. Go home you inbred C programmers and Billy-Joe-PHP'ers. You are the rednecks of the computing world. You are the fly-over programming languages that keep us busy wondering who uses your language as we our active records fly over your heads.
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
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.