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."
Java != Javascript (Score:2, Funny)
Struck out (Score:2)
No-one said otherwise. The only thing in TFA I could see to which you might be erroneously referring is the Mozilla Rhino, a javascipt implementation for Java -- which is exactly what it is. Maybe someone's in a bit too much of a rush to use the word "moron"?
Re: (Score:2, Funny)
Maybe someone needs to look up the word "Preemptive"?
Schindler's List? (Score:5, Funny)
schindler's list looks neat. I'll go read it sometime.
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.
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.
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
Or write CSS-compliant browsers. Nobody implements CSS fully.
Re: (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 "fun
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: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.
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: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.
Re: (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
What about a Comparison Matrix (Score:2)
Can someone point me to a comparison matrix for PHP, Perl, Tcl, Python, Ruby, and Javascript detailing advantages and disadvantages, pros and cons for each? I hope someone will do precisely that and I will be glad.
Note: I only know PHP and Ruby.
Re:What about a Comparison Matrix (Score:5, Funny)
Language | Turing Complete?
PHP | yes
Perl | yes
Tcl | yes
Python | yes
Ruby | yes
Javascript | yes
Re:What about a Comparison Matrix (Score:5, Funny)
Language | Has a "p" in it's name
PHP | yes
Perl | yes
Tcl | no
Python | yes
Ruby | no
Javascript | yes
Re:What about a Comparison Matrix (Score:4, Funny)
Tcl and Ruby have a p in their name, but the p is silent... as in swimming.
Forgot some important ones (Score:2)
LOLCode | yes
Turing machine descriptions | yes
Re: (Score:3, Funny)
Javascript | yes
Are you really sure?
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:
Re: (Score:2)
Cross-platorm
Yes, but the problem is, most JavaScript has to be tested on Firefox, IE, Safari, Opera, Konqueror, etc. And most likely you will be rewriting code or removing features to make it work on IE or older versions of Safari, Opera, Konqueror, etc.
Jaxer (Score:2, Informative)
Clearly you haven't heard of Jaxer [aptana.com].
Re:What about a Comparison Matrix (Score:5, Funny)
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.
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: (Score:2)
You cannot change types in Python variables implicitly. You have to do type conversions.
you can't do:
print "some string" + some_integer
You have to convert it:
print "some string" + str(some_integer)
Nice troll though...
Re: (Score:2)
You are quite right. But it still applies to evil creatures like PHP.
Re: (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.
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: (Score:2)
Actually, most (all? Not that familiar with Tcl) of those languages are strongly typed. The typing is just dynamic, that's all.
And I hope you were joking about them being evil. That is just silly, considering the history of their featuresets, derived as they are from Lisp.
Re:What about a Comparison Matrix (Score:5, Funny)
TCL is very strongly typed. Everythin is a string. That's a 100% unbreakable typesystem :-)
Re: (Score:2)
Haha, excellent, thanks for the info.
Re: (Score:3, Funny)
Yeah? So what?
In Javascript everything is a var.
So it is strongly typed too.
Re: (Score:2)
Javascript certainly isn't - everything is treated as a string most (but not all) of the time, which is a pain in the bleeding neck when suddenly 1+1 == 11.
Re: (Score:2)
I simply don't understand the whole breed of scripted languages that tossed out any kind of strong typing. I guess I can understand some quick-and-dirty batch language, and maybe that's where it comes from. Maybe they're all just descendants of csh.
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".
Re: (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: (Score:2, Informative)
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: (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: (Score:2)
No, its not, though Web browsers are the most well-known JavaScript environments.
Re: (Score:2, Interesting)
How about Firefox? Thunderbird?
I have; Microsoft had something which did this several years ago.
Re: (Score:2)
That's not true of the main, stable version of Ruby (MRI 1.8.x), though its true of Ruby 1.9 and some alternative implementations.
If it were more dynamic, and newer, they might; the distinction does seem pretty arbitrary and not all that useful.
Re: (Score:2)
That's not true of the main, stable version of Ruby (MRI 1.8.x), though its true of Ruby 1.9 and some alternative implementations.
Thanks, I wasn't aware of that. Of the languages listed, the only ones I have extensive experience in are Python and Perl.
Agreed about the uselessness of the distinction, too.
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: (Score:3, Insightful)
One good reason Java isn't a scripting language: it's impossible to write a script in it:-)
Re: (Score:2)
"Scripting language" is certainly ill-defined, but I'd suggest that the concept is an interpreted language with minimal overheads in the syntax. The latter tends to mean dynamic typing, but that's not really the important thing IMHO.
Re: (Score:2)
My understanding of scripting language:
1. Has lots of bindings to libraries and tools which are written in other languages, usually compiled ones.
2. Is used for gluing third-party code and external programs and for high-level logic as opposed to grunt work and computations.
3. The source file is the presumed redistribution form of the program, and is directly runnable.
4. Features aimed at programmer convenience rather than preventing errors or improving performance, which includes dynamic typing.
This makes P
Re: (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 compil
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: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.
Re: (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: (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.
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: (Score:2)
I'm guessing they wanted to include Microsoft and since Microsoft isn't a significant player in the scripting language area, they picked Microsoft's best scripting project, even though it isn't particularly important within the Ruby community.
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.
Re: (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:Major players? (Score:5, Funny)
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.
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:quality and libraries, but quality of libraries (Score:2)
I've had the same experience with CPAN: the code is often not very good, or the library doesn't really do what you expect it to do - a lot of contributions seem to be half-baked. In contrast, I have had a good experience with Tcl libraries. Perhaps one reason is that people put the half-baked stuff on the wiki (http://wiki.tcl.tk [wiki.tcl.tk]), where it is labeled as such, and don't present a full package until it is reasonably mature.
Re: (Score:2)
Perhaps. I suspect CPAN ironcailly also suffers from it's own ubiquity and ease of access. Any highschool student can whip together a quick Perl module, and I suspect more than a few do. The result is that poorly written or only half-baked projects end up there.
By contrast, the only people writing Tcl modules are those serious about using the language, and that immediately introduces a selection bias.
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.
Re: (Score:2)
What's your beef with Tcl? Perhaps the changes aren't in the features you don't like, but Tcl has seen major changes over the years and is still actively developed.
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: (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: (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.
Future of scripting langauges (Score:2, Funny)
Re: (Score:2)
Shaper [netspace.net.au].
Specifically designed to create a digital consciousness from a seed value of 700MB (the amount of data held within our human DNA).
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)
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
Re: (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: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.
Good timing (Score:2, Interesting)
Another Perspective on Dynamic Languages (Score:4, Insightful)
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*
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: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.
Osborne (Score:5, Informative)
You're recalling the Osborne Effect [wikipedia.org]. I sure hope that doesn't befall Perl.
Re: (Score:2)
That's it! I couldn't think of the name for the life of me.
I'm kind of afraid that's exactly what's happening to Perl. It promises to be so much better than Perl 5 that people are unwilling to commit to Perl 5 development for new projects.
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.
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...
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: (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.
Re: (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: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: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: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)
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: (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: (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: (Score:3, Informative)
Re: (Score:3, Funny)
Pffft, Perl is perfectly good for anything that needs string manipulation and such.
Unfortunately for Perl, so is Python. [xkcd.com]
(Well, and Ruby. I'm partial to Ruby, but there's no XKCD for me to link to.)
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: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: (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: (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: (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 w
Re: (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).