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."

Comments

Java != Javascript

[Anonymous Coward]

Preemptive strike! You're a moron, and Java != Javascript!

Re:Java != Javascript

[wisty]

Wait, what is a scripting language? Is it an interpreted language? Does it need inbuilt OS and string functionality (which Python needs to import, so it isn't a scripting language). If it needs to be flexible and dynamic, aren't Erlang and Lisp also scripting languages?

Schindler's List?

[PunkOfLinux]

schindler's list looks neat. I'll go read it sometime.

Re:Schindler's List?

[Anonymous Coward]

Why is this BS modded funny?

Caught in a crossfire

[ilovesymbian]

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

[MightyMartian]

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:Caught in a crossfire

[clang_jangle]

CSS is only "fundamentally fucked" because hardly anyone can be bothered to code CSS compliant web pages. It's a shame, really.

Re:Caught in a crossfire

[arevos]

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.

Could you perhaps expand on that? CSS deals with page layout poorly, and it's somewhat badly implemented in IE, but there's nothing I can think of that's fundamentally wrong with it. And I can't think of very much fundamentally wrong with Javascript DOM manipulation, either.

Re:Caught in a crossfire

[Tumbleweed]

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.

Not a great analogy to make your point, because when talking about scripting languages in that way, perl is basically that weird old guy down the street who keeps trying to talk little kids into coming into his house to play with his new puppy. *shudder* There's just something *wrong* with that guy.

Re:Caught in a crossfire

[Serious Callers Only]

The mixed up models of inline, floated and block content, which have organically grown from the web's origins as a set of lines of text, and been hacked to sort-of work as a layout algorithm, but CSS is hardly elegant.

Page layout is supposed to be its job, and yet it's still very difficult to lay out simple multiple column layouts in CSS with consistent results. Padding and the box model are so byzantine as to confuse even the browser vendors.

On top of that the handling of typography and other niceties of design is appalling (and not just because of browser inconsistencies, because it wasn't considered important).

Re:Caught in a crossfire

[FishWithAHammer]

Or write CSS-compliant browsers. Nobody implements CSS fully.

Re:Caught in a crossfire

[hobo sapiens]

I see where you are coming from, but don't blame CSS on bad implementations. Once you learn proper CSS and enforce some standards (such as avoiding inline stuff and class bloat) then it is very elegant.

People who don't like CSS and decry it as ineffective haven't implemented CSS layouts. Oh sure, they use some CSS to lay out their pages. But they don't truly do CSS layout.

It's a bit impractical and...well, kinda touchy feely, but csszengarden.com is a good working example of a true CSS layout. And yes, this can be done in a way that's practical in a business environment.

Re:Caught in a crossfire

[Jonboy X]

perl is basically that weird old guy down the street who keeps trying to talk little kids into coming into his house to play with his new puppy. *shudder* There's just something *wrong* with that guy.

Perl: The language of choice for pedophiles.

Re:Caught in a crossfire

[arevos]

Page layout is supposed to be its job, and yet it's still very difficult to lay out simple multiple column layouts in CSS with consistent results. Padding and the box model are so byzantine as to confuse even the browser vendors.

I did say that CSS deals with page layout poorly, but it doesn't seem a fundamental failing to me. You could solve it just by adding in better layout controls and deprecating much of the current way CSS handles layout.

Re:Caught in a crossfire

[Crazy Taco]

I am getting more comfortable with Javascript, though I still think DHTML and CSS are fundamentally f*****,

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...

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.

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

[FLEB]

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 "fundamentally fucked". I hate to say it, but the flawed IE box model, where fundamental dimension declarations (width/height) include margin/padding/borders, makes a whole lot more sense and involves a whole lot less manual math when you're trying to align disparate parts together.

Re:Caught in a crossfire

[xero314]

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

[Serious Callers Only]

I did say that CSS deals with page layout poorly, but it doesn't seem a fundamental failing to me.

In a module whose primary purpose is page layout (not markup), I'd say it's a pretty important failing. What they have tried to do is as you suggest - solve it by adding better layout controls, but it's now quite a confusing message of models (absolute position, floating, inline, block), with the default being a confusing mix of inline and block, and without any fine control on vertical alignment.

Still, it's a nice idea to have presentation files separate from the content, so I suppose you could say that the original idea is sound, but the implementation leaves something to be desired.

Re:Caught in a crossfire

[Serious Callers Only]

I see where you are coming from, but don't blame CSS on bad implementations. Once you learn proper CSS and enforce some standards (such as avoiding inline stuff and class bloat) then it is very elegant. People who don't like CSS and decry it as ineffective haven't implemented CSS layouts. Oh sure, they use some CSS to lay out their pages. But they don't truly do CSS layout.

It's a bit impractical and...well, kinda touchy feely, but csszengarden.com is a good working example of a true CSS layout. And yes, this can be done in a way that's practical in a business environment.

I have done lots of CSS stuff thanks - I use CSS exclusively on web pages. Whenever you find yourself saying 'People who...' you should step back and question your assumptions.

The reason I'm criticising it is I have used it extensively, on many sites. The default is inline for many elements, and the inconsistent handling of padding and margin by browsers indicates to me that there is something very wrong with the spec (confusing). It's not intuitive, particularly if you add floats and relative/absolute positions to the mix, and takes a while to master, so no, I wouldn't say CSS is elegant, and the comment is not born of ignorance.

For example, the only way to get columns to fill with colour at 100% height in all major browsers is to make them overflow and cut them off - hardly intuitive. Getting a multi-column layout to work well has taken a lot of effort from talented designers - given that's one of the most common layouts, it's insane that CSS makes this difficult - search for multi column holy grail, and then consider why they used that figure of speech - 'holy grail' for something that should be humdrum.

cssgarden is a really nice demo, and the *idea* of CSS (separating view from model) is great, but the layout model of CSS is not well done.

Re:Caught in a crossfire

[Z00L00K]

Still - there is a general failure on a higher level where there are expectations that systems written entirely out of script languages are better than systems written in a compiling language.

It may work from the beginning, but as soon as maintenance starts on the system there will sooner or later be problems. Especially if you have different people doing the maintenance compared to the people developing.

Re:Caught in a crossfire

[jimdread]

Still - there is a general failure on a higher level where there are expectations that systems written entirely out of script languages are better than systems written in a compiling language. It may work from the beginning, but as soon as maintenance starts on the system there will sooner or later be problems. Especially if you have different people doing the maintenance compared to the people developing.

What are you trying to say? Are you saying that maintenance on a system written in a "scripting language" will cause problems, but if the system was written in a "compiled language", then maintenance won't cause any problems? Do you think that it's easier for a person to read code they didn't write if it's written in a compiled language as opposed to a scripting language? Have you ever heard of the International Obfuscated C Code Contest? How is it possible to write obfuscated code in a compiled language?

Why do you think it's a "general failure" if systems written in a scripting language are better than those written in a compiled language? Wouldn't it make sense that the best systems are written in the most powerful languages, regardless of whether the language is compiled or interpreted? Did you know that some languages such as Lisp and Perl can be compiled or interpreted, depending on what the user prefers?

Re:Caught in a crossfire

[IamTheRealMike]

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.

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:Caught in a crossfire

[Kent Recal]

Yea, right. zengarden is a fairly trivial layout to start with (2 columns) and many of their examples don't even get that one right. Try increasing your font-size. Try making your browser window really small. Get the idea?

Nobody who has used CSS professionally (which you obviously haven't) would call it "elegant". Yes, some of the ideas and concepts are elegant but that's dwarfed by the development process, a series of trial & error, and the end-result, an amalgam of conditionals, hacks and kludges.

Re:Caught in a crossfire

[Kent Recal]

You could solve it just by adding in better layout controls and deprecating much of the current way CSS handles layout.

And what exactly would then be left of CSS as we know it? The practice of describing the layout in a separate ruleset?

If that's all you admit to be worth keeping of CSS then well, I would indeed call that a fundamental failure.

Re:Caught in a crossfire

[xero314]

I don't see how you can claim it's a "huge hindrance" - you sound like something of a cowboy programmer to be honest.

That's kind of funny. My teams always complain that I am to structure and process oriented. I would say it's my application of engineering practices that allows me to be able to safely work with dynamic and duck typed languages.

And yes it is true the more popular languages are strong static typed, but that does not mean it is the best way. And I have been doing mostly Java development professional for the past few years so I am very familiar with strong static typing and the libraries available for such languages. The majority of those library use object interrogation or even proxying to deal with the limitations of Strong static typing (Java's even includes an entire API to circumvent the limitations of strong static typing in it's Relection API). Even the majority of the design OO design patterns are design specifically to deal with these limitations.

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.

In JS you declare and define your types up front, so I'm not sure what you are getting at. Yes, it is possible to extend your type once it is created, but that neither means that you have to or that this should cause any reduction in maintainability. You have the option to use JS without ever once adding functionality to an object once it is created. Learn JSs object model and how to create constructors and you will understand more about how easy this is.

I rarely run into a bug that would be caught by a compiler, either in dynamic, static, weak or string typed languages. Bugs that can be caught by compilers are trivial in nature. You are better off having a good suite of test cases to catch bugs.

Optimizations on run time parsed languages are actually much easier than compile time languages. This is why Java now uses a Just in time Compiler, and that this has caused great improvements in performance. Plus there are multiple native/byte code compilers for JS, so it's not beyond reason that dynamic and duck typed languages can be compiled.

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 performance issued in browser application development have nothing to do with JS performance, it has to do with the browser implementation, and more importantly the DOM. This is why things such as XUL were devised. They provide a more application oriented object model and greater performance. It's also possible for JS to access native libraries, which is the only way to gain good performance in any language (even Java, C# and other byte code languages have an interface for accessing native code and utilize it highly in their core APIs).

Just do a little more research into JS, and understand the core features of the language. You will see that bad and inefficient JS code has nothing to do with the language.

Re:Caught in a crossfire

[MightyMartian]

There's enough proprietary crap out there for app development. Marrying yourself to yet another doesn't seem like a good idea to me. The web was supposed to be a universal protocol, but Microsoft fucked that up, and now your advocating Adobe, which is also well on the way to fucking it up even more.

Re:Caught in a crossfire

[hobo sapiens]

Nobody who has used CSS professionally (which you obviously haven't) would call it "elegant"

Hahaha, I have watched CSS grow up since I started using it professionally about 8 years ago. Get serious. CSS is fine. Yes, there are hacks and inconsistencies, but anyone who *has* done professional web development for any length of time knows through experience what to use and what to stay away from. CSS could also be better, but you have to understand that it has been held back only by the browser makers, and by "browser makers" I mean MSFT.

"Elegant" is subjective. I think CSS has an elegance to it, and you clearly don't. My experience has been that people who don't truly understand a technology are the quickest to dismiss it. Look at all the javascript haters in this discussion. Case in point.

Re:Caught in a crossfire

[hobo sapiens]

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 y" then, yes, this is harder.

You could justifiably say that you shouldn't have to work so hard to design a layout. Fair enough, laying out some designs requires some clever CSS footwork. But that's where experience comes in.

Maybe you've used CSS quite extensively. In my past experience (and I have been a professional web developer for many years now) when people complain about CSS being no good, it's only because they don't know how to do what they want to do. Maybe that's not you, I dunno.

Oh, and while I see your point about how CSS is too kludgy, don't misplace the blame on the CSS spec. There is really only one browser anymore that doesn't adhere reasonably well to the spec. And that company also doesn't adhere to HTML specs, or many others. It took them ten years just to understand alpha-blended pngs. It's not the specs, it's the software company that shall remain nameless.

Re:Caught in a crossfire

[IamTheRealMike]

I do understand JavaScript, for what it's worth. By "declare types up front" I mean declare them in things like function prototypes and variable declarations. If I look at some random JavaScript function, it can be very hard to figure out things about it because there's no type information. If I look at some random function in (well written) C++ then I do at least have something to work with - I can find the relevant declarations in the codebase quite easily and understand what the functions inputs and outputs are.

I agree with you that Javas type system is pretty worthless for finding bugs, and is so limited that it results in painful verbosity and lots of workarounds. That's a problem with Java though, not static typing in general. You can even have static typing without lots of type declarations in a language that can figure that stuff out automatically (eg Haskell) but most "production" languages limit the amount of type auto-discovery they do to function scope, again because otherwise it can get hard to figure out what code does.

I also agree with you that DOM interaction is too slow in modern browsers, and that if JavaScript became magically very fast that'd still be an issue. But JavaScript is also quite slow, and fixing that is, today, a research problem. I disagree that accessing native libraries is the only way to get good performance in "any language" - Java and C# provide native interfaces for operating system integration and legacy code support. Modern compilers (jit or otherwise) for Java and C# are very good and can produce code just as performant as the equivalent C, although sometimes with larger memory overhead (due to the design of the languages, not the compilers).

Re:Caught in a crossfire

[sowth]

I think a rational means of dealing with dyamic content would be: use a real programming language. Using a document format augmented with a script language intended to verify form data as a base for applications does not seem rational to me.

Re:Caught in a crossfire

[Serious Callers Only]

I think that many, not all, people who don't like CSS are more used to developing fat client apps.

I don't care to speculate on people who don't like CSS, unless you actually have some data to back up your preconceptions? I'll ignore the veiled insults and try to elucidate the areas I feel CSS is weak on.

Multi-column layouts in css is not intuitive at all - you have to nest columns in a particular order and in a container, set overflows, and if you want padding and column backgrounds to work you have to add extra divs inside your columns (insanity!). It should be as simple as something like (inline css used for brevity)

[div style="width:'80%';display='column';"]
      Content
[/div]
[div style="width:'20%';display='column';"]
      Sidebar
[/div]

It's not. Given that multi-columns on a grid is the default layout mode for most of the web, and for most design elsewhere, it's interesting that the default layout mode for CSS is inline, with blocks which are essentially inline elements with paragraph breaks, which I suspect is a throwback to the origins of the spec as a text layout model. CSS has no concept of baselines or grids (a basic element of design), and doesn't make it intuitive to lay things out on a grid. I my opinion the layout model is broken and needs to be radically simplified by adding simpler layout models and deprecating the mess we have currently.

For those who have used CSS a long time (NB, I have too, and feel at ease producing CSS layouts and adjusting for broken browsers), the pain may seem part of the process, but it should not have to be, and compared to other areas of design (for example print layout, PDF), it's needlessly byzantine. The problem lies with the spec, which is over-complex and is a mish-mash of too many layout models (inline, float, absolute, relative, text-align), not just with the browsers.

I much prefer it to the alternatives, but it's definitely the lesser of evils.

Re:Caught in a crossfire

[hobo sapiens]

"I don't care to speculate on people who don't like CSS, unless you actually have some data to back up your preconceptions? I'll ignore the veiled insults and try to elucidate the areas I feel CSS is weak on."

Come on, please. It wasn't a veiled insult. Fat client development is a different mindset. If someone is accustomed to one way of thinking, moving to another paradigm is sometimes difficult. It's not an insult to say that someone might be used to working a certain way and finds difficulty in working a totally different way. Didn't you caution me about making assumptions a few posts ago?

I think the rest of your post makes good points. And I think you also kind of proved my point about being used to a different mindset on laying things out. You think in terms of grids (or tables, or anything else with rows and columns.) That's ok IMO, it's a perfectly logical way of thinking. The difficulty that people have with designing for the web is the preference for a grid type layout prevents them from seeing layout as being fluid.

To really grok CSS, you have to stop thinking in terms of grids and start thinking in terms of flowing layouts. Let the browser place things, you just tell it sort of which order to place things in and how to place them with relation to one another. Yes, this is a bit of an oversimplification, but is the basic idea to keep in mind.

The design pseudocode you wrote above wouldn't work in a browser, or at least wouldn't be practical. What size is the browser window? You don't know. And do you really want your menu to shrink down past a certain point?

Re:Caught in a crossfire

[Serious Callers Only]

Didn't you caution me about making assumptions a few posts ago?

Yes, I did, this was a repeat of that message. I don't develop fat clients, and thus your paragraph probing in that direction was irrelevant.

You think in terms of grids (or tables, or anything else with rows and columns.) That's ok IMO, it's a perfectly logical way of thinking. The difficulty that people have with designing for the web is the preference for a grid type layout prevents them from seeing layout as being fluid.

I don't think exclusively in terms of grids, they're just a useful tool, and grids can also be fluid. Look at the page these words are on - it's designed on a grid, (2 sidebars, main content). Almost every web page is designed on a grid, and yet we have to hack around a lot with CSS to get something so simple.

If you take a look at the source of this page, you'll see a whole series of nested div - div - div which should not be necessary, but are there to work around complications with CSS. This is in my view a good illustration of the inappropriate 'features' of the CSS layout model.

I do really grok CSS (as I said, all sites I've done in since CSS1 came out have used it, I've always written them by hand), and I happen to think it's a bit of a mess. You persist in imagining that I don't know what I'm talking about, simply because I disagree with you. Strange.

Inline(character) and block(paragraph) layout flow is fine for *text layout* - they originate in laying out text on series of lines, with inline images glommed on. They are not a viable way to style anything other than text, and most of the effort designers put in to using CSS is in fighting the inline with blocks model, plus of course to work around various browser bugs.

The whole box model with padding adding to the width of elements is also completely counter-intuitive. Here's an article explaining this bizarre misfeature for beginners :

http://developer.apple.com/internet/webcontent/css_horizontal.html

That article should not be necessary.

The design pseudocode you wrote above wouldn't work in a browser, or at least wouldn't be practical. What size is the browser window? You don't know.

That's why the widths were in percents (to adjust with the window), and yes, it would work if CSS had a sane layout model. Why wouldn't it be practical in your opinion?

And do you really want your menu to shrink down past a certain point?

That's what a min-width/max-width specification is for - obviously those styles weren't complete, it's just a simplified example of something very very common that CSS does very badly and requires lots of nested divs for and a fair amount of CSS hackery.

That you can't simply and easily layout a website using columns is a serious failing of CSS, given that almost every website uses this model. That you can't add padding to an element without a nested div is also a failing in my opinion; one which stems from the model's origins as a text layout model, centred on text blocks rather than box elements. I prefer it to the other options (tables, or no layout at all), but it is ugly in some respects, and not at all elegant (save perhaps the idea of separating content from presentation).

What about a Comparison Matrix

[bogaboga]

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

[Surt]

Language | Turing Complete?
PHP | yes
Perl | yes
Tcl | yes
Python | yes
Ruby | yes
Javascript | yes

Re:What about a Comparison Matrix

[El_Muerte_TDS]

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

[grahamd0]

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:

• Functions are objects
• Objects are functions
• Cross-platorm
• Easy to learn
• Will blow your mind when you finally gaze upon it's vast majesty

Cons:

• Slowish
• Client-side only

Re:What about a Comparison Matrix

[arcanumas]

You are wrong. There are scripting languages with dynamic but strong typing like Python for example.
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:What about a Comparison Matrix

[Darkness404]

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.

Re:What about a Comparison Matrix

[abigor]

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

[serviscope_minor]

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

[serviscope_minor]

TCL is very strongly typed. Everythin is a string. That's a 100% unbreakable typesystem :-)

Re:What about a Comparison Matrix

[MightyMartian]

You are quite right. But it still applies to evil creatures like PHP.

Re:What about a Comparison Matrix

[Foofoobar]

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.

Re:What about a Comparison Matrix

[meuhlavache]

Damn, mIRC Scripting don't make me a real programmer? You killed me!

Re:What about a Comparison Matrix

[abigor]

Haha, excellent, thanks for the info.

Re:What about a Comparison Matrix

[Tony Hoyle]

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:What about a Comparison Matrix

[MightyMartian]

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.

Re:What about a Comparison Matrix

[Bromskloss]

Javascript | yes

Are you really sure?

Re:What about a Comparison Matrix

[Surt]

pretty sure.
http://en.wikipedia.org/wiki/Turing_complete

Re:What about a Comparison Matrix

[arodland]

And then there's perl, where + is reserved for addition, and . is concatenation, and you don't need casts or stupid crap like "" + foo. Ah, the wonders of making different things different.

Re:What about a Comparison Matrix

[nitroamos]

Of the list, I only have significant experience with Perl and Python. For my limited purposes, Perl is preferable because it facilitates the use of regex so much better. In perl, you just say $foo =~ /regex/, but in Python, you have to import the package, compile your regex, and then you can use it.

Why don't more scripting languages build regex functionality into the language?

Re:What about a Comparison Matrix

[grahamd0]

Meh. The only things you really to worry about with cross-browser javascript are transparency, window dimensions, and AJAX, all of which can be taken care of by using whichever of a dozen or so freely available libraries you prefer.

Re:What about a Comparison Matrix

[Tassach]

I prefer Perl's way of doing it:
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.

Re:What about a Comparison Matrix

[Anonymous Coward]

Looks like we've got a Tcl fanboy.

Re:What about a Comparison Matrix

[serviscope_minor]

Looks like we've got a Tcl fanboy.

Didn't you read the comparison matrix? TCL doesn't have any fanbois.

Re:What about a Comparison Matrix

[Peaker]

Yeah, all hundreds of them.

The wonders indeed.

Re:What about a Comparison Matrix

[maxume]

In python, you do have to import a module, but you don't have to compile the regex before you use it.

re.compile('blah').search('t blah t') is equivalent to re.search('blah', 't blah t'). Some small number of recently used patterns are cached by the re module, so compiling only really matters when that number of patterns (I think, around 20) are being used together.

I don't think in a given day that the difference would really add up to all that much time spent or timed saved, in either direction. The python is probably more readable for the uninitiated, but that doesn't matter all that much. I imagine the reason it isn't syntax in Python is that there is a preference for keeping the language smaller when the option presents itself.

Re:What about a Comparison Matrix

[0100010001010011]

And when you've learned that, write php to write your javascript for you. The similarities in the languages will drive you mad ;).

I only use this for AJAX using prototype. Prototype will 'eval' any returned data if you tell it to (or its doctype is javascript). That means you can call "login.php" and have it return a javascript, which can update your page. Fun stuff.

Re:What about a Comparison Matrix

[FishWithAHammer]

You are quite right. But it still applies to evil creatures like PHP.

PHP6 may introduce an optional strong-typing feature down the line. Not for 6.0.0 (where it should be), but there may be hope.

Re:What about a Comparison Matrix

[chromatic]

I suppose if you want a minimal language with a few things you have to remember (whether operators, standard library functions, core objects, monads, or whatever), you want the SKI combinator calculus. The problem with that is you have to reinvent the universe just to make an apple pie.

Re:What about a Comparison Matrix

[istartedi]

Language | PiTA when version X.x is no longer supported and you need to upgrade?
PHP | yes
Perl | yes
Tcl | yes
Python | yes
Ruby | yes
Javascript | yes

At least, if you are big enough to control the server (as opposed to being Joe Blow using a hosting company) you can control when the upgrade occurs. OTOH, if the old version has security issues your hand is forced. Javascript is in the browser, so any change to the implementation that breaks your code may get sprung upon you at any time. I haven't actually used Tcl, but I've read about it, and it's been around a long time. Perhaps this one is the most stable, but who uses it for major web sites?

Re:What about a Comparison Matrix

[ehynes]

• Objects are functions

What does that mean?

Re:What about a Comparison Matrix

[427_ci_505]

That is a terrible hack, but then I suppose we are talking about perl after all. =D

Re:What about a Comparison Matrix

[DragonWriter]

Untyped languages are evil evil evil evil evil evil evil evil evil. They're designed by lazy-ass programmers for other lazy ass programmers. If you want to change variable type, then you should be forced to explicitly cast, not have the dumb-ass interpreter do it for you.

In dynamic languages, variables often don't have types, so talking about changing the type of a variable doesn't even have any meaning. In some languages, values don't really have types beyond "object" (classes in OOP are not the same things as types in general, though the concepts may be conflated in certain languages) so talking about changing the type of values wouldn't make sense, either.

Further, the use of profanity does not mask the absence of either evidence or reasoning offered to support your position.

Re:What about a Comparison Matrix

[hobo sapiens]

Ok, so what do *you* prefer?

Java? Don't even get me started on Java...

Re:What about a Comparison Matrix

[nitroamos]

Sorry, the example in my initial post didn't best illustrate my complaint. But here's what I wanted to do in python:
                        line = re.compile("old").sub("new",line)

In perl, I'd only have to say:
                        line =~ s/old/new/;

The issue for me is not speed, but clarity, and accordingly I think other script languages should add an "=~" operator. I guess this hardly matters in the end. But it does ruffle my feathers.

Re:What about a Comparison Matrix

[maxume]

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:What about a Comparison Matrix

[dash2]

Tcl and Ruby have a p in their name, but the p is silent... as in swimming.

Re:What about a Comparison Matrix

[iceyone]

Javascript has server side interpreters... Rhino & Tamarin come to mind.

Re:What about a Comparison Matrix

[ignavus]

Yeah? So what?

In Javascript everything is a var.

So it is strongly typed too.

Re:What about a Comparison Matrix

[eosp]

Theorem. Javascript is Turing-complete. Proof. Brainfuck is Turing-complete. Any Brainfuck program can be converted to JavaScript (it is well known how to do this in C, and it's easily ported.) Therefore, JavaScript is a superset of the functionality of Brainfuck. QED.

Re:What about a Comparison Matrix

[sootman]

Then PHP wins because it has TWO! :-)

Re:What about a Comparison Matrix

[donaldm]

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:

• Functions are objects
• Objects are functions
• Cross-platorm
• Easy to learn
• Will blow your mind when you finally gaze upon it's vast majesty

Cons:

• Slowish
• Client-side only

Err no!

Choosing a language is dependent on what is required to do a particular job. Too many people start to program first with a language they are comfortable with and with only a vague idea on what is required, after all you don't program in a compilable language when a few simple or maybe not so simple commands with appropriate options will do the work in a fraction of the time.

When I say "required" I don't mean what you or even the customer wants, it may be but if you analyse the problem from an initial overview and work down to finer details, that is "What do we want to achieve here and how should this be achieved?" Once you get this right and it may take a while so good communication skills are essential, especially if you work with people who's primary language is not yours. Choosing a programming language or even languages if appropriate, should be made only when everyone knows what is required. Getting it "right" is much more appropriate than just picking a programming language and hacking, although it may not be as much fun.

Now I will do the "monkey dance". Write, Test, Document, Write, Test, Document, Write, Test, Document .......:-)

Re:What about a Comparison Matrix

[bucky0]

Javascript is a yes??

Re:What about a Comparison Matrix

[piojo]

I recently had a similar problem, and as a result, wrote a script in perl instead of python:
...
elsif ($str =~ /($release)\./) { do something with $1;}

If someone could tell me how to do this nicely in python, I'll buy you a beer (if you live near me).

Re:What about a Comparison Matrix

[nitroamos]

Ok, I'm glad to see that the compile was unnecessary when I edited a script a couple months ago. I wonder why I had concluded otherwise...

I guess this is just another example of an opinion biased by a misunderstanding! :-)

Re:What about a Comparison Matrix

[SuperMog2002]

javascriPt

Re:What about a Comparison Matrix

[riceboy50]

Perl has that weirdness with the $_ variable, which allows it to be more cryptic.

Re:What about a Comparison Matrix

[DocHoncho]

to make a new object Foo with members Bar and Baz you would write

function Foo(x)
{
  this.Bar = x;
  this.Baz = "Wakka";
}

and instantiate it with

myFoo = new Foo(42);

weird, isn't it?

Re:What about a Comparison Matrix

[rmelton]

You can create your own table with whatever weightings you want at the language shootout page: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all

Note that I linked the Gentoo/P4 platform since it has the most ranked entries.

Re:What about a Comparison Matrix

[DocHoncho]

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///).

It gets even better if some schmuck decided to use different delimiters... s!foo!bar!

Yuck. I'm not a perl hater but I'll be damned if you can't do some really awful shit with it.

Re:What about a Comparison Matrix

[bucky0]

wow. just wow. that's the biggest brain fart I've had in a long long long time.

Re:What about a Comparison Matrix

[xero314]

I think you are very confused. In JavaScript a Number is a Number and a String is a String. The fact that you are trying to add 1 + "1" doesn't mean there is anything wrong with JS. Objects are only treated as Strings when a string is required, or it does not meet the criteria for any of the other applicable objects. Read the specification sometime. There is a hierarchy for auto casts for every operations.

If the operation is over loaded to work with Strings or Numbers the operation will treat all the objects in the operations as numbers if they are all numbers, otherwise it has to treat them all as strings, as every object can be treated as a string. It's actually far more detailed than that, but I'm not going to rewrite the spec in a slashdot comment.

Just try and remember that 1 == "1" but 1 !== "1".

Re:What about a Comparison Matrix

[chromatic]

If you have trouble with $_ in Perl, avoid pronouns and implied subjects in imperative sentences in English. (You seem to use the word "it" correctly, so you should be able to use $_ correctly in Perl.)

Re:What about a Comparison Matrix

[riceboy50]

I didn't say I had trouble, I said it allows Perl to be more cryptic. Also, comparing it to English doesn't exactly make the case for simplicity.

Re:What about a Comparison Matrix

[gnud]

You kinda forgot events. But a library will fix that, too.

Re:What about a Comparison Matrix

[dkf]

Language | PiTA when version X.x is no longer supported and you need to upgrade?
Tcl | yes

[...]

I haven't actually used Tcl, but I've read about it, and it's been around a long time. Perhaps this one is the most stable, but who uses it for major web sites?

It certainly used to power the main AOL site for many years (instead of that slow rubbish called Apache :-)). And indeed you're doing Tcl a disservice, since it's generally possible to upgrade from X.x to X.y (xy) without having to recompile anything at all (!) or change scripts. Stuff from 10 years ago still works just fine. (OK, it still looks like stuff from 10 years ago. But at least upgrading the language doesn't force you to rebuild the rest of the world...)

Re:What about a Comparison Matrix

[dkf]

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.

It's good for sticking bits together. Those bits can be written in whatever strongly-typed language you want (I admit I like using C, but tastes vary and there's not a lot to read into the fact) but when you're making the glue to turn everything into an application, those fancy strong types tend to get more in the way than not. Use the right tool for the task and save yourself a lot of grief. (And don't forget to strongly verify the type constraints when moving from the un-/loosely-typed world of the glue to the strictly-typed world of the components.)

Re:What about a Comparison Matrix

[owlstead]

So "1" + "1" = "11"? Bead counting? Didn't know that :)

Re:What about a Comparison Matrix

[Jedi Alec]

Oh god, the horrible memories.

I wrote a complete irc framework in Perl just to be able to get away from mIRC :P

Re:What about a Comparison Matrix

[WWWWolf]

It gets even better if some schmuck decided to use different delimiters... s!foo!bar!

What about it? Which is more readable,

$line =~ s/<(\/?)b>/<$1strong>/gi;

or:

$line =~ s!<(/?)b>!<$1strong>!gi;

And this is a non-pathological case. Please don't ask me to match URLs, it gets a bit uglier.

In my opinion, LTS is one of the worst things that kills code readability, and allowing people to pick string delimiters that fit the situation is the best possible way to make the code is legible.

Perl is ugly in many ways, but what comes to the string delimiters, it's much more elegant than many other languages, and I wish other languages would let people to pick their string delimiters too. The reason people say that Perl is a good language for regex stuff is that in other languages you get megatons of unreadable quote-character mess, while Perl lets you write regexes in clear way that you can actually make sense of later on - and same goes for other string literals.

Re:What about a Comparison Matrix

[maxume]

It probably won't qualify as nicely, but I think the best you can do is this:

# prior to if/else/elif stuff
mo = re.search(r'(%s)\.' % release, str)
if...
elif mo:
    one=mo.group(1)
    ...

The alternative is to execute the match once to check the condition and then again in the else block to capture the match object:

elif re.search(r'(%s)\.' % release, str):
    mo=re.search(r'(%s)\.' % release, str)
    one=mo.group(1)
    ...

Re:What about a Comparison Matrix

[Kent Recal]

That's okay. Many refer to it as javascribbel anyways.

Re:What about a Comparison Matrix

[grahamd0]

Javascript and PHP have built in regex.

Re:What about a Comparison Matrix

[Tangent128]

The tricky part is when dealing with variables- that number from that form field, is it still a string, or did you convert it with "num=num*1" already?

Mind you, I still love Javascript; it just requires cauton.

Re:What about a Comparison Matrix

[chromatic]

Also, comparing it to English doesn't exactly make the case for simplicity.

Everything depends on whether you want a simple language or simple programs. I said earlier that the SKI combinator calculus is a simple language -- but good luck writing simple programs with it. Complexity always goes somewhere.

Re:What about a Comparison Matrix

[xero314]

I'm still not seeing the issue. A String object is a String object. If you can't remember if you that the object you are working with is a number of not then use the NaN function to make that determination first. This same thing would happen in any other language with an overloaded + operator.

I'm just saying that JS gives you the tools necessary to not make these mistakes if you are every dealing with unknown object types and using primitive operations (not a problem if you use method calls as you are safe as long as the object supports the method being called, which is also easy to check).

Re:What about a Comparison Matrix

[Allador]

The words I would use, rather than 'weird' would be: silly, unnecessarily obtuse, stupid, etc.

What are the types of Bar and Baz? How do you make sure your fixed-point decimal numbers dont get accidentally coerced into floats (and thereby getting randomly rounded)?

How do you distinguish between public and private members?

I really really dont get the fascination of developers with JavaScript. If you want to do real work with tools, interfaces, and declared types, then there are better solutions. If you want to work in a dynamic language, there are better languages (python & ruby, others).

The ONLY bene I can see of JavaScript is that (some flavor) of it is in each browser. Of course, that 'different flavor' problem is a royal PITA.

Re:What about a Comparison Matrix

[grahamd0]

Lisp and Scheme might be better languages to learn from an academic standpoint, but from an "I get paid money for this" pov, javascript is a much more practical language.

Re:What about a Comparison Matrix

[shutdown -p now]

Curiously enough, "It's not COBOL" is also universally applicable to all of those, but I'm not sure if it counts as an advantage or as a disadvantage for Perl...

Re:What about a Comparison Matrix

[piojo]

Thanks. I like the second possibility--if I'm parsing DB table names, then the regex match time is not a bottleneck, and it would not normally occur to me to write a line twice, even when it's the most readable way to do it.

Scripting language. What is it?

[serviscope_minor]

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:Scripting language. What is it?

[BitterOldGUy]

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:Scripting language. What is it?

[Thought1]

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.

Re:Scripting language. What is it?

[abigor]

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:Scripting language. What is it?

[Anonymous Brave Guy]

"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:Scripting language. What is it?

[broken_chaos]

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:Scripting language. What is it?

[DragonWriter]

Agreed, as Python, Ruby, etc. are compiled to byte code which run on virtual machines, just like Java...

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.

yet no one calls Java a scripting language.

If it were more dynamic, and newer, they might; the distinction does seem pretty arbitrary and not all that useful.

Re:Scripting language. What is it?

[DragonWriter]

JavaScript is web browser-only, client-side scripting.

No, its not, though Web browsers are the most well-known JavaScript environments.

Re:Scripting language. What is it?

[broken_chaos]

I was referring to the most common usage (though I had a feeling someone was going to decide to pick at that...). I've never, ever seen JavaScript used for or run in such a way that it's not intended to be used with a webpage (though I have seen semi-standalone JavaScript interpreters, they're mostly intended for working out bugs without using a full browser).

Or if you want to look at it the other way, I've never seen Python/Perl/Ruby scripting capabilities embedded in a browser, setting them apart in the same way.

Re:Scripting language. What is it?

[Tweenk]

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 PHP, Perl, Bash script (and to some extent Python, since there are many pure Python libs) canonical scripting languages, and Java and C++ canonical non-scripting languages.

Re:Scripting language. What is it?

[abigor]

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?

[chromatic]

I've never, ever seen JavaScript used for or run in such a way that it's not intended to be used with a webpage...

How about Firefox? Thunderbird?

I've never seen Python/Perl/Ruby scripting capabilities embedded in a browser, setting them apart in the same way.

I have; Microsoft had something which did this several years ago.

Re:Scripting language. What is it?

[serviscope_minor]

C can be, if you have the tcc compiler installed.

Re:Scripting language. What is it?

[broken_chaos]

Hm, good point. I usually forget about Mozilla-style UIs, since I'm not a huge fan of... Chrome, is it, that they call it? Applying web rendering principles and styles to a browser UI just seems sloppy to me, not to mention all the troubles with integrating into various OSes and not looking horridly out of place. (Gecko, on the other hand, I don't mind. I do have a problem with the huge bloat, though. Part of that is (notably the compile time) probably attributed to it being in C++.)

Well, that just goes back to square one then, about trying to figure out how they're defining scripting languages...

Re:Scripting language. What is it?

[ericlondaits]

Flash is scripted through ActionScript, which is (at least was, before ActionScript 3.0) basically JavaScript (or a slight variation of it). The Mozilla Platform (used for Firefox, Thunderbird, Songbird, Komodo IDE, etc.) is integrated and can be extended with Javascript. VXML (Voice XML) which is a language for specification of interactive telephony applications uses Javascript in a similar way to webpages. AFAIK HD-DVD uses javascript as well.

If you have Windows chances are you have the Windows Scripting Shell (WSH) installed, which includes two programs (WScript.exe and cscript.exe) which can be used to execute Javascript and VBScript files in the shell for various tasks).

I myself have programmed many systems which host Microsoft's JS parser (ActiveScript) allowing me to control various low-level objects through js scripts, in the same way that scripts in web pages allow you to control objects in the DOM, ActiveX objects, etc. Just hours ago I made a js script which accesses a database and sends an e-mail with some tabulated data. Once, in a robotics class at my university, we had to write a program that would control a robot (Khepera) from the computer... I did a full COM wrapper to the robot's API, which allowed me to program the behavior through Javascript... at first I got a few laughs and snickers from my choice of language, but I was the only one that could test changes without recompiling my program.

Re:Scripting language. What is it?

[Zerth]

I've never, ever seen JavaScript used for or run in such a way that it's not intended to be used with a webpage

You can use JavaScript to control photoshop. I think you can use it to script stuff in Indesign as well.

Re:Scripting language. What is it?

[Abcd1234]

This is all decidedly off topic, but... :)

Applying web rendering principles and styles to a browser UI just seems sloppy to me

Meh, matter of taste. What about XAML? Or any of the other mechanisms used for defining UIs? I'm not sure Chrome is any worse of better than any of them. And it does have the advantage of being extremely malleable at runtime, which his pretty nifty.

not to mention all the troubles with integrating into various OSes and not looking horridly out of place

And, of course, that has absolutely nothing to do with Chrome, and is simply an artifact of Mozilla opting to write their own widget set, ala Swing, as opposed to binding to native controls, ala SWT. TBH, I'm not really sure how I feel about that decision... on the one hand, it makes maintenance a lot easier (no need to maintain platform-specific widget bindings), and ensures that the implementation is 100% consistent across all platforms. But, as you say, it does mean Mozilla seems a tad out of place. 'course, so does Winamp, Windows Media Player, Office 7...

I do have a problem with the huge bloat, though. Part of that is (notably the compile time) probably attributed to it being in C++

Buh? The latest round of tests have shown that, as far as memory usage is concerned, Firefox 3 is the leanest browser out there. Much of that comes down to optimizations in Gecko, changes in the way XPCOM-bound objects are garbage collected, etc.

Re:Scripting language. What is it?

[ToasterMonkey]

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:Scripting language. What is it?

[frank_adrian314159]

Maybe it's "dynamically typed and either interpreted or runs on a virtual machine"?

Damn. There goes Lisp. It's usually complied these days (even if it is being run interactively).

Re:Scripting language. What is it?

[larry bagina]

Macromedia (now Adobe) products use javascript for application scripting. PDF also has javascript support, and Flash's ActionScript is a javascript derivative. Microsoft's cscript/wscript support javascript (vbscript is more common, though). And of course, ASP and ASP.NET can be javascript.

Re:Scripting language. What is it?

[abigor]

No, I don't think it's derogatory at all, just a rather inexact term. Python isn't interpreted in the sense that, say, bash is, as it compiles to bytecode. So it's tough to use "interpreted" to describe both.

Javascript doesn't have an interactive prompt (that I know of), nor can it be executed with #!/usr/bin/foo. But it's commonly referred to as a scripting language. Same with all the ECMAScript derivatives, such as ActionScript. Are they not scripting languages, then? They fail both of your tests.

Re:Scripting language. What is it?

[hellwig]

...yet no one calls Java a scripting language

Shit, I'll say it: Java IS a scripting language.

Anyone ever play Vampire the Masquerade (PC version, not table-top) back in 2000? Remember what language it used to script game-sequences? That's right, Java. -QED

I would think a program created in a language would have to run on it's own to NOT be considered a scripting language, but that's just my opinion. Personally I don't consider Java a programming language because you have to use a JVM to run it in (instead of running natively within the environment). But don't listen to me, I still program professionally in crazy languages like Ada.

Re:Scripting language. What is it?

[DragonWriter]

I've never, ever seen JavaScript used for or run in such a way that it's not intended to be used with a webpage (though I have seen semi-standalone JavaScript interpreters, they're mostly intended for working out bugs without using a full browser).

I've never, ever seen a live collosal squid, nevertheless, I'm quite aware that they exist. Similarly, while I've never seen non-demonstration desktop or server-side JavaScript usage, I'm well aware that that exists.

Or if you want to look at it the other way, I've never seen Python/Perl/Ruby scripting capabilities embedded in a browser, setting them apart in the same way.

The current lack of widespread browser support (combined with widespread browser support of JavaScript) does keep that from happening much, though there are a number of efforts to host those in a browser environment to allow them to be used that way (Microsoft, IIRC, is pushing technology that lets you run anything that runs on .Net in a browser, including IronRuby, IronPython, etc.; Mozilla has a project to build support for non-JS scripting languages on top of their new VM used in their JS engine; there is the HotRuby VM, which is a VM executing Ruby 1.9 bytecode that is written in JS to allow pre-compiled Ruby to run in a browser or other JS environment; and so on.)

Re:Scripting language. What is it?

[zoips]

Beanshell. Tada! Java scripting, not to be confused with Javascript.

Re:Scripting language. What is it?

[zoips]

Spidermonkey

Interactive shell and supports shebang.

Rhino

Interactive shell but doesn't support shebang.

Re:Scripting language. What is it?

[zmooc]

One good reason Java isn't a scripting language: it's impossible to write a script in it:-)

Re:Scripting language. What is it?

[init100]

Personally I don't consider Java a programming language because you have to use a JVM to run it in (instead of running natively within the environment).

Then you're likely one of those crazy guys who think that scripting languages are not programming languages? I never really understood that opinion, so if you share it, maybe you can explain it to me.

In my opinion, scripting languages are a not-so-well-defined subset of programming languages, not a separate category of languages. After all, you program the computer regardless of whether the language is compiled or interpreted.

Re:Scripting language. What is it?

[broken_chaos]

Ah, with the bloat I mainly think about it in just how huge Firefox and such have become (not strictly in terms of speed or RAM usage). It was supposed to be the 'small and light' Mozilla, and it's source code is some 37M or something, compressed, for one thing. I used to run Gentoo quite a bit, and compiling XUL Runner (more or less Gecko only) took around 30 minutes (about the same as glibc, or gcc!) on a C2D system with ... Uh, 2 gigs of RAM. The only other applications/libraries I remember being -that- nasty was... QT, the toolkit. I even did a quick comparison and SeaMonkey (the updated Mozilla suite) was actually faster at running than Firefox, oddly enough.

I remember running it on an old system (PII, ~400 MHz) and even version 1 would take a good 40 seconds to load...

Maybe I just have unobtainable standards on how a good browser should work/be. ;)

Re:Scripting language. What is it?

[bill_kress]

Although there are a lot of correct answers, I think "Script" is more valuable as a classification of language types rather than how the language is compiled/interpreted/etc.

Common attributes of a modern scripting language:
-Entering 2 or 3 lines and running it is as easy as possible and has a useful result.
-Has language adaptations specifically for communicating with the OS
-More focus on being writable than readable.
-Minimal overhead
-Many "Features" built into the language
-Language features are usually dynamic and adapts to changes rapidly

A modern development language on the other hand:
-consistency in the language
-less language features, let the libraries do the work.
-Being explicit so it's readable and its organization can be understood.
-Not into "Elegant", (Elegant tends to be less readable, it's explicit instead)
-Controlled language development, slower and more deliberate.
-Backwards compatibility is important.

Scripting languages tend to be much more powerful per character. They also often allow features that would devastate large team development such as the ability to modify the global environment and modify "Finished" classes.

You actually want to avoid power in a development language. You want to see every single thing that happens in your class written out in that class file. Typing speed and code is almost completely unimportant (DRY is still CRITICAL, as are small classes... don't think I'm arguing against those!), but the ability to clearly translate a model, and to restrict programmers from unhealthy choices is critical.

Re:Scripting language. What is it?

[DrSkwid]

If you end up staring down the gun of an ASP project, you'll be glad Javascript is there waiting for you with a pair of sunglasses and a JD & coke.

Re:Scripting language. What is it?

[grumbel]

Lets turn that question around: Unless a language is self hosting, i.e. written in itself, I wouldn't call it a 'full' language.

Re:Scripting language. What is it?

[JesseMcDonald]

Can anyone come up with a really good definition of a "scripting language"?

I think it comes down to (a) being able to run the program without explicitly compilation, and (b) little or no mandatory boilerplate code.

Java: Explicit compilation to .class file. Requires class declaration and entry-point method for the simplest programs. Conclusion: not a scripting language.

Ruby/Perl/Python/JavaScript: Implicit compilation, or interpreted. No boilerplate code. Conclusion: scripting languages.

Bash: Interpreted. No boilerplate code. Conclusion: scripting language.

C: Generally requires explicit compilation. Requires explicit entry-point routine. Conclusion: not a scripting language.

TCC can be used to run pseudo-C code as a "script", but one could create a wrapper for any language that compiles to a temporary file and then runs the result. I think the typical use case is a better indicator.

Re:Scripting language. What is it?

[prockcore]

I've never, ever seen JavaScript used for or run in such a way that it's not intended to be used with a webpage

CouchDB uses javascript to do queries.

Re:Scripting language. What is it?

[prockcore]

I posted this to the xkcd forums last year:

#!/bin/sh
/usr/bin/gcc -xc - <<EVILEOF

#include <stdio.h>

int main()
{
        printf("C as a shell script\n");
}

EVILEOF
./a.out

Re:Scripting language. What is it?

[francium de neobie]

LISP gives you an interactive shell as well. But you can compile LISP code to make it run faster. Same for Python, though I don't know how much a .pyc file is faster than a .py file.

Anyway, with languages like LISP or Python, I can perfectly give you a compiled software package based on these "scripting languages" that you'll have a hard time modifying with a text editor. And (for LISP at least), there's a very substantial difference in performance (sth. like 100x for math intensive stuff) between executing the compiled file and the source file - substantial enough that well-written compiled LISP code can approach the performance of a compiled C executable.

If the interactive shell is just a feature of the language, yet you can compile it so that you can distribute the software without the source code, and have the performance of traditional compiled languages as well - then, would it be so important to distinguish the language into scripting vs. "real" anymore? The scripting part can just be seen as a feature of the language, but on the other hand it may be able to do anything a "real" language can do.

Re:Scripting language. What is it?

[ignavus]

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:Scripting language. What is it?

[francium de neobie]

You can also write a JavaScript prompt in a browser yourself by using a text area and the eval() function. Or typing "javascript: ..." in the URL bar, or using the Firebugs console.

So, yes, JavaScript DOES have an interactive prompt.

Re:Scripting language. What is it?

[david_thornley]

Which would include Lisp, which is also a dynamically typed language. I don't think that's what most people mean, although it'd make a wonderful scripting language if it was easier to interact with the OS.

Re:Scripting language. What is it?

[BotnetZombie]

It's not impossible. Just run your Java code with the scripting language Groovy. It runs on the JVM and can accept any Java source. But it also has closures and some more syntactical sugar, so I guess it would be cheating to say that Java is a scripting language even if Java source can be used that way.

Re:Scripting language. What is it?

[julesh]

Javascript doesn't have an interactive prompt (that I know of),

Netscape used to have one, but it seems to have been removed from modern Mozilla projects. You can run javascript interactively by typing 'javascript:[statement]' into your URL bar, though.

Re:Scripting language. What is it?

[julesh]

Unless a language is self hosting, i.e. written in itself, I wouldn't call it a 'full' language.

Disagree. It must be _possible_ to produce a self-hosted implementation of the language, but it isn't necessary for anyone to actually do so, I.M.O.

Why? First, the language that the implementation you are using has little actual effect on the usefulness of the language you are using (unless that language is sub-optimally efficient, in which case it may diminish that usefulness).

Also, we're moving into an era now where single components (class libraries, virtual machines, parsers, optimizers, machine-specific object code generators) are more and more commonly shared between multiple language front-ends. It would be silly to classify a language as "not full" just because its implementers decided not to reinvent the wheel and reused somebody else's work to simplify their own job.

Example: the leading Ada95 compiler is GNAT. GNAT is an Ada front end that uses the back end optimization and platform-dependent output sections from GCC, which are obviously written in C. Is Ada therefore not a "full" language? The notion is absurd: by any reasonable definition of "full", Ada95 should probably be one of the leading examples.

Re:Scripting language. What is it?

[pommiekiwifruit]

Any language that doesn't scale well to real work :-)

Re:Scripting language. What is it?

[abigor]

I stand corrected - thanks very much.

So what about ActionScript? ;)

Re:Scripting language. What is it?

[hellwig]

By programming language, I think of the language actually running the program. Languages like Java and C# are scripting langauges because they tell the environment what they want to do, and the environment (JVM, .NET, etc..) actually does the work. You could do the same in C, by using third-party libraries and only calling into those libraries, but the libraries themselves are usually written in C as well. JVM and .NET are both written in C/C++. In my opinion this makes C/C++ the programming language, and Java and C# are scripting into the environments. By that same logic, something like SmallTalk might also not be a programming language but a scripting language, since it runs inside an VM. However, Squeek, a SmallTalk VM, is also written in SmallTalk, so I really don't know where to go with that one.

The issue with Java and C# is that they are entrenched inside of these environments. Java is basically managed C with a whole bunch of modules/library's that make it much friendlier to program. Since those modules are standardized in the JVM, it's much more portable than a raw C progam, assuming someone writes a JVM for your platform.

Here's the way I look at it, is the language compiled down to assembly/machine code, then assembled and linked into a running program? Or, is the language interpreted into a second high-level language, then executed through pre-compiled/assembled modules (i.e. Java -> C++ modules -> assembly)?

Please note that I consider the OS a platform, not environment, so arguing that Windows or Linux is actually doing the executing doesn't make C a scripting language. Also, I remember hearing in college about them developing a physical machine that would run Java (i.e. JVM on silicon), did they ever make on of those?

Re:Scripting language. What is it?

[shutdown -p now]

Can anyone come up with a really good definition of a "scripting language"?

The only one I can think of that makes at least some sense is, "a language for which REPL is possible".

Re:Scripting language. What is it?

[init100]

Languages like Java and C# are scripting langauges because they tell the environment what they want to do, and the environment (JVM, .NET, etc..) actually does the work.

Not entirely, as the JIT in most cases generates native code on the first invocation of a method/function call, and the code is cached for future use. That native code is then executed directly on the processor, just like native code generated by the C compiler.

In my opinion this makes C/C++ the programming language, and Java and C# are scripting into the environments. By that same logic, something like SmallTalk might also not be a programming language but a scripting language, since it runs inside an VM.

I consider any language used to write programs for a computer a programming language, regardless fo whether it is compiled, interpreted or something in between. Then there are subsets, such as compiled languages, interpreted languages, languages executed as bytecode in a VM, etc. I strongly disagree with the notion that a scripting language is not a programming language.

However, Squeek, a SmallTalk VM, is also written in SmallTalk, so I really don't know where to go with that one.

A perfect example of why your view causes problems with terminology.

Or, is the language interpreted into a second high-level language

I wouldn't call Java bytecode or similar languages "high-level", as high-level usually implies human-readable. It is a machine-independent machine language interpreted and/or JIT-compiled by the JVM.

Please note that I consider the OS a platform, not environment, so arguing that Windows or Linux is actually doing the executing doesn't make C a scripting language.

That's an entirely reasonable position, as the OS does not interpret the native code. When an application is running on the processor, it really is its compiled code that is running there, not some interpreter.

To sum it up, the line between interpreted languages and compiled languages is becoming more and more blurry. Some languages are completely interpreted, some languages are completely compiled into machine code, and many languages use some combination of interpretation and compilation.

Personally, I use the term scripting language for languages that do not need a separate compilation stage (good examples of this are those that can be executed by running the source file directly in *nix by including the #!interpreter notation on the first line of the source file). They may be internally JIT-compiled, but that isn't my business. I do not consider languages explicitly compiled into some intermediate form to be scripting languages. But I consider all of them to be programming languages.

Syntax argument.

[BitterOldGUy]

I started reading the article and then I got bored at page three.

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.

[belmolis]

Yeah, yeah, one language make it easier for the programmer to manipulate text or to develop some functionality for a particular task.

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:Syntax argument.

[Just Some Guy]

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.

[Anonymous Coward]

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.

Re:Syntax argument.

[Thiez]

> 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.

Clearly you have never seen perl.

Re:Syntax argument.

[Greenmoon]

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.

[francium de neobie]

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:Syntax argument.

[julesh]

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.

You seem to have a large-company oriented image of the world. Let me broaden your horizons a little: approximately 99% of the businesses in the developed world have fewer than 500 employees. OK, so a lot of these won't have CIOs (or people with equivalent titles, like mine: IT Director). But many do. Enough that probably 80-90% of CIOs in the world are working in these companies.

These CIOs don't have development managers to assist them with these details. They have to interact directly with developers themselves, or, in some cases, have to _be_ developers themselves. So, yes, a large majority of CIOs do, in fact, have to concern themselves with the specifics of implementation in this fashion. For them, being a CIO _is_ a tech management job.

Struck out

[clang_jangle]

Preemptive strike! You're a moron, and Java != Javascript!

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:Struck out

[75th Trombone]

Maybe someone needs to look up the word "Preemptive"?

Major players?

[Peter Cooper]

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:Major players?

[belmolis]

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?

[Esther Schindler]

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:Major players?

[belmolis]

What! Introducing actual facts on /.?

Re:Major players?

[Esther Schindler]

Oh my. Don't tell anyone I did that.

Re:Major players?

[coryking]

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.

Re:Major players?

[piojo]

If you use Ruby, people call you by your initials, not your name.

Thank you for that wonderful post :)

Re:Major players?

[Esther Schindler]

Lynn asked the Big Cheese(s) who to talk with. Ya think she ought to have said, "No, that guy isn't cool enough"?

Re:Major players?

[Peter Cooper]

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?

[shutdown -p now]

Microsoft's a major player generally, but in the Ruby world they are not.

How many Ruby implementations are there, again?

I'd argue that people behind every one of those (including JRuby and IronRuby) are pretty damn important.

Re:Major players?

[Peter Cooper]

Depends on your definition of "important" - important to those ecosystem crossovers, but not necessarily "important to Ruby" generally. It's like asking a quarterback of a college team to talk authoritatively about football. They're gunna have opinions, but you really should be asking a manager of a top team or someone in the Dallas Cowboys or something.

Re:future of perl?

[Just Some Guy]

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.

quality and libraries, but quality of libraries?

[bcrowell]

[Perl] has the lowest defect rate of any open-source software product. [...] It has readily-accessible libraries for all types of programming tasks: Web application development, systems and network integration and management, end-user application development, middleware programming, REST and service-oriented architecture programming.

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.

Things haven't improved much.

[Animats]

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:Things haven't improved much.

[belmolis]

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.

[Bogtha]

They all still suck for about the same reasons they sucked three years ago.

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.

Three years ago, ctypes wasn't part of the standard library. It is now, and it's great, not troublesome at all.

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.

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.

Re:Things haven't improved much.

[magus_melchior]

In my experience, Ruby syntax tends to be easy to read and maintain compared to Javascript or Perl, although you are still free to obfuscate it to your heart's content-- its rather libertarian syntax allows Java coders and shell scripters to continue using their respective styles, which is nice if they want to try it out. Many of the language features that Ruby proponents bring up are often found in some way or another in Python, Lisp, or Perl. Being relatively new to the scene, it has fewer well-developed libraries, which may change with more developers using Rails.

I don't know if that helped much, I just code in it; I haven't really delved into how the language works.

Wikipedia should have more info than I do.

Re:Things haven't improved much.

[Abcd1234]

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:Things haven't improved much.

[spaceyhackerlady]

What's your beef with Tcl?

As a former colleague put it, "A theoretically perfect computer science language you can't actually do anything with."

I'm writing lots of python nowadays. It's almost as handy as perl, without perl's write-only tendencies.

...laura

Re:Things haven't improved much.

[korbin_dallas]

Of all the langs listed TCL is the only one that goes to PPC405 and half a dozen other embedded system processors out there. The only one with a very nice and easy to use single file packaging system for deployment to other major systems. The only one with portable gui toolkit. And all in a very small deployment package.

Doing guis in perl, ruby or python?...probably with Tk huh?

Re:Things haven't improved much.

[Abcd1234]

In my experience, Ruby syntax tends to be easy to read and maintain compared to Javascript or Perl,

My problem with Ruby is that it's just unlike Smalltalk enough to be annoying. See, when I first came across it, I thought "hey, it's like Smalltalk, but scripted! I can get behind this!" Then I started digging. For example, take the horrible hack that is passing closures to functions. WTF? A special, magic syntax so you can pass in closures, and you can only pass in *one*? Once you see that, suddenly you realize that closures *aren't* first-class objects in Ruby, despite what the language would have you believe.

Little things like that are what anger me about languages. Above all, a programming language should be internally consistent. Say what you will about Python or Perl, but at least they're consistent. The same can't be said for Ruby, which ends up looking a bit amateurish as a result; the product of someone who knew just enough Smalltalk to screw up what could've been a rather nice little language.

Re:Things haven't improved much.

[belmolis]

You can't do anything with Tcl? How about BitKeeper?

Re:Things haven't improved much.

[chromatic]

Only someone who hasn't been paying attention would believe that.

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:Things haven't improved much.

[xant]

So what's the schedule for a release? Not a troll, I just know (because I am a release manager) that if you are talking about an imminent release, and you don't have a list of issues to fix and a schedule to go with them, then you are not going to release soon. Until I see a schedule, the comparison to DNF sticks.

Re:Things haven't improved much.

[Abcd1234]

if you are talking about an imminent release

Umm... I'm not. I explicitly said there *wasn't* an imminent release. What I said was that Perl 6 is making huge strides, and that it's far from vapourware. Go to the Parrot project website, download a development snapshot, and see for yourself.

Until I see a schedule, the comparison to DNF sticks.

Only if you don't understand the two projects. DNF has an ever-changing target of requirements and specifications... hell, it's changed engines, what, three times? Perl 6 has a largely complete language specification, a large and growing test suite, two separate implementations in the works, and many people working hard to develop a complete implementation. Is there still a ton of work to do? Absolutely! But it's *far* from being the clusterf*ck that is DNF, and you do the project a great disservice by making such a poorly educated comparison.

Re:Things haven't improved much.

[cecom]

It's interesting that nobody uses Java applets much any more. It's worth understanding why that failed. But that's another subject.

It is really very simple. A Java applet takes extremely long to load even on a very fast machine. It is ridiculous. In all other respects Java applets are vastly superior to JavaScript and Flash, but who cares ? Alas, the speed of loading and initializing a JVM cannot be addressed without a major re-design of the entire language.

Re:Things haven't improved much.

[spaceyhackerlady]

You can't do anything with Tcl? How about BitKeeper?

I didn't say I agreed with that particular colleague. :-)

...laura

Re:Things haven't improved much.

[murr]

I explicitly said there *wasn't* an imminent release.

Which is the Perl 6 problem in a nutshell.

What I said was that Perl 6 is making huge strides,

Perl 6 has made huge strides since 2000. The question is whether progress of the project will ever catch up with the goal posts.

For all the "progress" and "huge strides", Perl 6 still seems to lack an authoritative voice (whether that of a single person or a small group) with a single minded focus on convergence and shipping, and until that voice emerges, I'm pessimistic about Perl 6 ever shipping.

In fact, the longer development drags on, the more likely the developers are to self select for those who are perfectly content to live in a permanent state of daily development snapshots.

Until I see a schedule, the comparison to DNF sticks.

Only if you don't understand the two projects. DNF has an ever-changing target of requirements and specifications... hell, it's changed engines, what, three times? Perl 6 has a largely complete language specification,

After eight years, the best you can say about the language specification is that it's "largely" complete?

Is there still a ton of work to do? Absolutely! But it's *far* from being the clusterf*ck that is DNF,

Given that there is a substantial community of people depending on Perl for their work, and the same can hopefully not be said for DNF, Perl 6 is a much bigger disaster than DNF.

While Perl 5 actually has made substantial progress over the last few years (and seems to be as stable as ever), Perl 6 keeps siphoning off mindshare and developers.

Parrot threatened to throw other scripting languages into a similar state of confusion, but it appears that no other front end has reached the critical mass yet to be taken serious as a language implementation, so in this case, it seems that the debacle has been somewhat self limiting.

Re:Things haven't improved much.

[Abcd1234]

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:Things haven't improved much.

[francium de neobie]

If you want to write a GUI with Python, Perl and Ruby, you can use wxWidgets. Works for Mac OS X, Windows and *nixes.

Re:Things haven't improved much.

[chrono325]

WTF? A special, magic syntax so you can pass in closures, and you can only pass in *one*?

So sure there are some annoyances in Ruby. There are in any language. But you can most definitely pass more than one closure to a method (since everything is an object, there really aren't "functions" in the purest sense).

Observe:

p1 = lambda { puts "I am p1" }
p2 = lambda { puts "I am the other one. p2." }

def the_procs(arg1, arg2)
        arg1.call()
        arg2.call()
end

the_procs(p1, p2)

#=> I am p1
#=> I am the other one. p2.

You could even put the "lambda { blah }" within the function call so you didn't create intermediate variables.

Re:Things haven't improved much.

[kripkenstein]

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.

Speed isn't Python's forte, but it has no problem integrating with standard C modules. Ctypes lets you do it at runtime, and for 'static' development boost::python is wonderful.

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.

Not so, Ubuntu for example ships a perfectly-usable Python with fully-functional database interfaces, or at least I've never had a problem. I am sure this isn't unique to Ubuntu. Also nice is that Sqlite is built in to recent Python versions.

Also worth noting that ORMs like SQLAlchemy and Storm (which I personally use) are a single package away, making coding for databases in Python extremely efficient.

So it seems your complaints against Python are a little outdated. That said, you missed what is in my opinion the main remaining complaint against Python - the lack of true threading (due to the global interpreter lock). This makes pure Python implementations of large projects a little troublesome, however, a solution may arrive from a non-CPython location, e.g., Jython offers correct threading and is just about at the Python 2.5 level, running Django even.

Re:Things haven't improved much.

[chromatic]

For all the "progress" and "huge strides", Perl 6 still seems to lack an authoritative voice (whether that of a single person or a small group) with a single minded focus on convergence and shipping, and until that voice emerges, I'm pessimistic about Perl 6 ever shipping.

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:Things haven't improved much.

[julesh]

Many of the language features that Ruby proponents bring up are often found in some way or another in Python, Lisp, or Perl.

Hmm... I think that of those, only LISP supports statement blocks passed as parameters to a function, which is, you know, the key language feature of Ruby.

The only _other_ language I know that supports that is smalltalk.

I'd be happy to learn about other languages with the feature.

Re:Things haven't improved much.

[julesh]

For example, if you have a "return" statement in a block that's passed into a function, and the called function yields to the block, Ruby returns from the calling function, rather than "returning" from the block (yield'ing nil), and not returning from the called function either. However, if the called function wraps its block in a lambda before calling it (if, say it wants to pass it to another function like in your example), the same return statement in the block has a completely different effect, depending on how the block is used. I see why it was done, but don't think the overall design is right, especially if blocks are special like that but you can't pass multiple blocks into a function.

Coming from a smalltalk background, that'll be _exactly_ what's bothering the original poster. Smalltalk statement blocks use the former pattern rather than the latter, with the result that the design is _extremely_ neat. It lets you produce new flow control primitives, for example:

myTestMethod
      randomlyExecuteEither: [ ^ 1 ] or: [ ^ 2 ].

randomlyExecuteEither: block_a or: block_b
      | randomlySelectedBlock |
      "code to randomly assign either block_a or block_b to randomlySelectedBlock goes here"
      randomlySelectedBlock value.

When executed, the two statement blocks, "[ ^ 1 ]" (return 1) and "[ ^ 2 ]" (return 2) are passed to the randomlyExecuteEither:or: method, which picks one and executes it. This causes myTestMethod to return, not the closure, and not randomlyExecute.... The coding style it enables is clear, readable and very useful. You can do it in smalltalk or lisp, but not (it would appear) ruby. This is definitely to ruby's disadvantage.

Re:Things haven't improved much.

[murr]

For all the "progress" and "huge strides", Perl 6 still seems to lack an authoritative voice (whether that of a single person or a small group) with a single minded focus on convergence and shipping, and until that voice emerges, I'm pessimistic about Perl 6 ever shipping.

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.

I'm afraid I'm unable to parse your request with sufficient confidence to know what exactly you'd like me to list. Also, I fear you're asking me to discuss which people I don't consider focused on convergence and shipping, and I will not do that. I know too few of the current core contributors to decide whether they lack focus on shipping, or the authority to make the others focus.

Instead, let me give you a counterexample: For a while, Chip Salzenberg was the Parrot pumpking, which raised my hopes for Perl 6. As the Perl 5.004 pumpking, Chip had exactly the focus that I feel is missing from Perl 6 today.

Re:Things haven't improved much.

[chromatic]

I know too few of the current core contributors to decide whether they lack focus on shipping, or the authority to make the others focus.

That would have made an interesting disclaimer to your previous post, though I suspect it's much easier to criticize several anonymous strangers in bulk for their perceived shortcomings. We do nearly all of our work in public, as we have done for many years. We've made plenty of mistakes worth criticizing, yet most of the criticism we get is from people who've never looked at any of our work (and certainly none of our recent work).

Re:Things haven't improved much.

[murr]

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.

So did it get completed between the time you last posted and it was "largely" done, and now? Congratulations!

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?

I don't want "being done". I want "done".

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.

The THIRD iteration, after the first two iterations were DONE, FINAL, and widely implemented.

There's a difference between regular iterations and continuous tinkering.

And yet, C compilers abound.

C compilers implementing C89 or C99, the COMPLETED iterations.

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*.

You keep contradicting yourself. Are you sure you know what "finished" means? To the best of my knowledge, there isn't even a complete DRAFT available to the public. In what appears to be the most authoritative list, about half the chapters have not even been published as a draft, and about half of the rest are still marked as "DRAFT", so presumably not final.

Besides, you took one small quote and asked "is that best best you can say?".

I'm quite serious. Ada, which was a huge effort and must have been bogged down in enormous amounts of red tape (with both the DoD and a standards organization involved), went from CFP to published standard in 6 years. Perl 6 does not have a complete draft after 8 years.

Funny how you completely ignored the rest, such as the test suite,

I'll grant that this is a good thing to have.

and the two ongoing implementations.

I'd gladly settle for ONE, FINISHED, USABLE implementation.

As interesting as having Perl 6 implementation in Haskell is from an academic point of view, it's about the least likely practical deployment platoform I can think of.

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...

One of the concrete ways this manifests is in the funding of Perl 5 and Perl 6. According to the published records, the Perl Foundation awarded at least $200K in grants for Perl 6 development during 2000-2006. While the Perl 6 project may have attracted some of this funding, and some of the Perl 6 work was backported to Perl 5, I very much doubt that this adds up to being a net benefit for Perl 5.

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.

Yes, the Perl 6 effort has not killed Perl 5 progress entirely. That does not mean it hasn't hindered it.

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?

It's not the "new platform" that is the problem, but the vaporware existence of a platform that after more than 7 years still isn't shipping in stable form. Again, the distinction between stable, shipping products and endlessly evolving projects seems to elude you.

None of this would matter much if Perl 6 and

Re:Things haven't improved much.

[murr]

I know too few of the current core contributors to decide whether they lack focus on shipping, or the authority to make the others focus.

That would have made an interesting disclaimer to your previous post, though I suspect it's much easier to criticize several anonymous strangers in bulk for their perceived shortcomings.

I'm not all that interested in criticizing individuals. What is evident is that the PROJECT these individuals have pursued has been a massive failure.

I also don't think that lack of a focus on shipping is necessarily a "shortcoming" in an individual. There are plenty of people who are successful and productive, despite not being particularly shipping driven (and in many cases, probably BECAUSE of it). However, for a project that needs to ship, a lack of shipping driven people, or failing to put these people in charge at some point, is a fatal flaw.

We do nearly all of our work in public,

... and quite a bit of it by press release.

We've made plenty of mistakes worth criticizing, yet most of the criticism we get is from people who've never looked at any of our work (and certainly none of our recent work).

Ship it, and maybe you'll get the better class of critics you feel you deserve.

Re:Things haven't improved much.

[chromatic]

According to the published records, the Perl Foundation awarded at least $200K in grants for Perl 6 development during 2000-2006.

That could buy two years of a modestly-paid software developer's time (figure in self-employment tax, health care, et cetera). TPF crammed two funded developer years into six calendar years for Perl 6, and it's still not done. (We might be up to four funded developer years for the specification, the test suite, a virtual machine, and the language implementation.)

Again, the distinction between stable, shipping products and endlessly evolving projects seems to elude you.

No one has claimed that Parrot or Perl 6 is a "stable, shipping product" right now. If you really want to claim that this makes the entire project "vaporware", please feel free to apply that moniker to Ruby 2, PHP 6, Python 3.0, GHC 6.10, Java 7, ECMAScript 3.1, and a few hundred thousand other projects in progress -- at least, if you're at all interested in applying words fairly.

While the Perl 6 project may have attracted some of this funding, and some of the Perl 6 work was backported to Perl 5, I very much doubt that this adds up to being a net benefit for Perl 5.

You may find it interesting to hear that the reason Perl 5 (for one example) has orders of magnitude more core tests than Ruby or Python (and let's not mention how much the culture of testing has permeated the CPAN) is a direct result of the Perl 6 project. See slide 43 in Tim Bunce's Perl Myths 200802. (If you don't believe him, believe me, because I was there, I wrote a significant amount of them, and I did the research to which Tim alludes.)

Also, I'd love to see your list of widely-available, cross-platform C99-conforming compilers -- as someone who writes a fair amount of C code to run across several operating system and compiler combinations, I can think of several vendors who can't seem to support a decade-old C standard.

Re:Things haven't improved much.

[chromatic]

I'm not all that interested in criticizing individuals.

Individuals create projects. I'm sure if you donate years of volunteer work to a project and some random anonymous Internet crank whined all over about how awful your project management skills are, how you'll never finish, how you can't communicate, and how you've killed other valuable projects wasting away your time and skills, you might feel a little bit criticized as well.

However, for a project that needs to ship, a lack of shipping driven people, or failing to put these people in charge at some point, is a fatal flaw.

I welcome your reasoned and researched suggestions for how to ship faster then. Shall we berate volunteers for not working hard enough? Convince them to quit their jobs and pay them in shiny TPF scrip? Throw away lots of code and rewrite everything on the shiny new VM of the month? Cut back on features?

The appropriate mailing lists and IRC channels are public. Please note that no one will take you seriously unless you demonstrate a passing familiarity with the project's goals, its recent history, and the milestones. Likewise, handwaving and saying "You should really ship something" isn't useful.

... and quite a bit of it by press release.

Show me a press release from the past three (I believe even four) years which promises a target date or future work that we haven't accomplished. (For every press release which says "TPF funds developer $x for $foo", I'll point you to another public status report for that developer.) Meanwhile, I'll show you over a year and a half of monthly stable Parrot releases, which include the Rakudo implementation -- delivered on the third Tuesday of the month, showing visible, stable, regular progress.

Re:Things haven't improved much.

[k8to]

The problem with TCL: eval, upvar.

Re:Things haven't improved much.

[murr]

According to the published records, the Perl Foundation awarded at least $200K in grants for Perl 6 development during 2000-2006.

That could buy two years of a modestly-paid software developer's time (figure in self-employment tax, health care, et cetera). TPF crammed two funded developer years into six calendar years for Perl 6, and it's still not done. (We might be up to four funded developer years for the specification, the test suite, a virtual machine, and the language implementation.)

Nothing here that I disagree with, but I don't see how it addresses my point that Perl 6 consumed substantial resources, a considerable fraction of which could otherwise have gone to Perl 5.

Also, as modest as you believe this amount to be, it is, to my knowledge, vastly more cash funding than Perl 5 has received over its existence (total funding is hard to estimate, because prior to Perl 6, a lot of the funding consisted of companies allowing developers to spend part - sometimes the majority - of their time on Perl development; I don't know to what extent this practice has persisted).

No one has claimed that Parrot or Perl 6 is a "stable, shipping product" right now. If you really want to claim that this makes the entire project "vaporware", please feel free to apply that moniker to Ruby 2, PHP 6, Python 3.0, GHC 6.10, Java 7, ECMAScript 3.1, and a few hundred thousand other projects in progress -- at least, if you're at all interested in applying words fairly.

The reason I used that word is that Parrot was (a) announced with great clamor and (b) seven years later, still is not shipping. I don't think these criteria apply to any of the projects you cite.

While the Perl 6 project may have attracted some of this funding, and some of the Perl 6 work was backported to Perl 5, I very much doubt that this adds up to being a net benefit for Perl 5.

You may find it interesting to hear that the reason Perl 5 (for one example) has orders of magnitude more core tests than Ruby or Python (and let's not mention how much the culture of testing has permeated the CPAN) is a direct result of the Perl 6 project.

Again, I'm not denying that SOME of the Perl 6 work has benefited Perl 5. My question is whether Perl 5 got $120K worth of benefits (or whatever you consider a fair estimate of funding siphoned off by Perl 6). Besides, it's not like Perl 5 and CPAN modules used to come without extensive unit tests before the glorious Perl 6 revolution introduced them.

Also, I'd love to see your list of widely-available, cross-platform C99-conforming compilers -- as someone who writes a fair amount of C code to run across several operating system and compiler combinations, I can think of several vendors who can't seem to support a decade-old C standard.

Fair enough. "abound" was not my choice of words. At least C compiler vendors have a published standard to be held to - I noticed that you did not choose to reply to my paragraph about the Perl 6 spec still appearing to be far from complete.

Re:Things haven't improved much.

[chromatic]

Also, as modest as you believe this amount to be, it is, to my knowledge, vastly more cash funding than Perl 5 has received over its existence...

Untrue. O'Reilly funded Larry primarily to work on Perl 5 for several years, and ActiveState has paid several people to work on Perl 5 as well. I don't have exact dollar figures for any of those, but if my understanding is correct, the total spent primarily to develop Perl 5 exceeds the $200k spent on Perl 6.

I don't see how it addresses my point that Perl 6 consumed substantial resources, a considerable fraction of which could otherwise have gone to Perl 5.

That's RIAA/MPAA/BSA math. Volunteer interest and effort is not fungible. It never has been. It never will be.

Besides, it's not like Perl 5 and CPAN modules used to come without extensive unit tests before the glorious Perl 6 revolution introduced them.

I hate the argument from authority, but you're arguing with the guy who wrote the fundamental testing library that kicked off the pre-Cambrian explosion of testing in Perl 5. Yes, there were tests -- but they were inconsistent, often of mediocre quality, and poorly understood.

Parrot ... seven years later, still is not shipping.

We release a stable release on the third Tuesday of every month, as we have done every month since the end of 2006. Again, if you're at all interested in using words fairly, please call Ruby 2, PHP 6, Python 3.0, GHC 6.10, Java 7, ECMAScript 3.1 vaporware, as they release stable not-yet-final versions as well but somehow aren't "shipping" either.

I noticed that you did not choose to reply to my paragraph about the Perl 6 spec still appearing to be far from complete.

I prefer to discuss facts, not subjective impressions.

Re:Things haven't improved much.

[murr]

I'm not all that interested in criticizing individuals.

Individuals create projects.

Or, in the present case, FAIL to create them.

I'm sure if you donate years of volunteer work to a project and some random anonymous Internet crank

It's fascinating how somebody who uses their nom de plume even for their published books gets bent all out of shape over someone else using a chat handle.

whined all over about how awful your project management skills are, how you'll never finish, how you can't communicate, and how you've killed other valuable projects wasting away your time and skills, you might feel a little bit criticized as well.

I've been on the receiving side of that, lived to tell, and eventually figured out which part of the criticism was justified.

However, for a project that needs to ship, a lack of shipping driven people, or failing to put these people in charge at some point, is a fatal flaw.

I welcome your reasoned and researched suggestions for how to ship faster then. [...] Throw away lots of code and rewrite everything on the shiny new VM of the month?

In fact, I believe that the launch of Parrot was the original sin that truly doomed Perl 6. Doubling down on the scope of a complex project by trying to over-generalize a subproject never made sense to me.

Cut back on features?

Naturally, yes. That's how you generally get complex projects to ship: Figure out a reasonable, self contained subset of the totality of things you want to do and stop working on everything not part of that subset until you've shipped that.

In the case of Perl 6, that would mean:

• Completing the spec.
• Adding only those features to Parrot that are indispensible to support the Perl 6 spec
• Finishing Rakudo to implement that spec

Seems self-evident, doesn't it? But if it is, why are people working on Pugs at the moment?

... and quite a bit of it by press release.

Show me a press release from the past three (I believe even four) years which promises a target date or future work that we haven't accomplished.

Yes, that may have been the point at which the sliding 18 month release window was dropped. By then, a good part of the PR damage was done, however (It's not like DNF got a lot of publicity lately either).

Meanwhile, I'll show you over a year and a half of monthly stable Parrot releases, which include the Rakudo implementation -- delivered on the third Tuesday of the month, showing visible, stable, regular progress.

There is progress, yes, but is there convergence?

Re:Things haven't improved much.

[chromatic]

Or, in the present case, FAIL to create them.

Which parts of "We release a stable version of Parrot on the third Tuesday of every month, as we have done for the past two years -- and this includes Rakudo, an implementation of Perl 6 on Parrot" are difficult to understand? You can check out the past seven years of the project from our public Subversion repository. Do you live in a bizarro post-existential world where completion precedes existence?

In the case of Perl 6, that would mean [doing exactly what you're doing]...

If we're doing that wrong, please feel free to suggest what we should do instead. I'm sure our volunteer project managers would love nothing more than to hand off their lazy, slipshod, ignorant work to someone so obviously wiser, more talented, taller, more virile, and (hey, why not?) better looking.

[Why] are people working on Pugs at the moment?

Why do some people watch football and others lacrosse? Why doesn't everyone do everything exactly the way you say precisely when you say? Why aren't volunteers fungible? De gustibus non est disputandum! It's so unfair!

There is progress, yes, but is there convergence?

You're using the greatest research and publication tool known to mankind to ask a question you could answer for yourself! We publish daily statistics on Rakudo's progress passing the Perl 6 specification tests. (That is, you could find that information if you're not somehow stuck in a parallel universe where software magically springs into existence perfectly-finished only after weeks, months, or years of work from volunteers when the software doesn't exist at all, which despite protestations to the contrary, I suspect is not actually the case.)

Hm. Open mockery, with Latin, the many-worlds theory, and late 20th century philosophy. I suspect this shall be my final post in the thread.

Re:Things haven't improved much.

[murr]

Also, as modest as you believe this amount to be, it is, to my knowledge, vastly more cash funding than Perl 5 has received over its existence...

Untrue. O'Reilly funded Larry primarily to work on Perl 5 for several years

... and so did NetLabs. I know. That's why I wrote "cash funding", and discussed the sponsored employment situation in my next sentence, which you chose to omit.

and ActiveState has paid several people to work on Perl 5 as well. I don't have exact dollar figures for any of those, but if my understanding is correct, the total spent primarily to develop Perl 5 exceeds the $200k spent on Perl 6.

I'm sure sponsored employment for Perl 5 exceeded the $200K spent by TPF. However, are you claiming that this practice simply does not exist at all for Perl 6?

I don't see how it addresses my point that Perl 6 consumed substantial resources, a considerable fraction of which could otherwise have gone to Perl 5.

That's RIAA/MPAA/BSA math.

Bah. Only a Nazi would use that line of argument.

Volunteer interest and effort is not fungible. It never has been. It never will be.

My discussion was primarily about MONEY, which by definition IS a fungible resource.

As for volunteer effort, the picture is less clear. Some people, like yourself, have continued to contribute to Perl 5. Others, by refocusing their energies on Perl 6, may have done Perl 5 a favor as well.

Besides, it's not like Perl 5 and CPAN modules used to come without extensive unit tests before the glorious Perl 6 revolution introduced them.

I hate the argument from authority, but you're arguing with the guy who wrote the fundamental testing library that kicked off the pre-Cambrian explosion of testing in Perl 5.

I assume you're talking about Test::MockObject. I have no idea how many CPAN modules are using that (there seems to be no dependency cross reference). Of the subset of 593 modules ported to fink packages, a grand total of 9 (1.5%) seem to use Test::MockObject, of which 8 are Catalyst related. Could it be that you have a somewhat inflated sense of your role in history?

Yes, there were tests -- but they were inconsistent, often of mediocre quality, and poorly understood.

I submit that the world of CPAN was not quite as void and without form before you entered it as you make it out to be, and that you did not cast as much light into it as you believe.

I noticed that you did not choose to reply to my paragraph about the Perl 6 spec still appearing to be far from complete.

I prefer to discuss facts, not subjective impressions.

Does this mean that you're denying the fact that the Perl 6 spec is nowhere near complete?

Re:Things haven't improved much.

[murr]

Or, in the present case, FAIL to create them.

Which parts of "We release a stable version of Parrot on the third Tuesday of every month

What makes that version "stable"? It changes, as you point out yourself, once a month, passing countless new unit tests. It codes to an evolving spec and is targeted by an evolving compiler.

You can check out the past seven years of the project from our public Subversion repository. Do you live in a bizarro post-existential world where completion precedes existence?

I live outside the military-industrial complex, so in my world, progress reports don't equate completion.

In the case of Perl 6, that would mean [doing exactly what you're doing]...

[...] [Why] are people working on Pugs at the moment?

Why do some people watch football and others lacrosse? Why doesn't everyone do everything exactly the way you say precisely when you say? Why aren't volunteers fungible? De gustibus non est disputandum! It's so unfair!

It seems you still fail to see that you are NOT "doing exactly" what I suggested. Perl 6 is still plodding along as a tangle of vaguely correlated individual agendas.

There is progress, yes, but is there convergence?

You're using the greatest research and publication tool known to mankind to ask a question you could answer for yourself!

That is considerably harder than it might appear to you, as the websphere for Perl 6, like the project itself, is littered with false starts and dead ends.

We publish daily statistics on Rakudo's progress passing the Perl 6 specification tests.

I still have no idea what the canonical source of these statistics would be. What I found was this plot, according to which there is NO convergence, as the number of passed tests grows more slowly than the number of overall tests.

I suspect this shall be my final post in the thread.

Suit yourself

Re:Things haven't improved much.

[chromatic]

I assume you're talking about Test::MockObject.

You keep making faulty assumptions...

Could it be that you have a somewhat inflated sense of your role in history?

... and you keep jumping to faulty conclusions.

The module to which I alluded still has my copyright and credit prominently in its documentation, and it's a dependency of probably 95% of distributions uploaded to the CPAN in the past three -- and perhaps five -- years (including Test::MockObject), and there are ports to at least four other languages. That seems a fairly tangible side benefit of Perl 6.

I submit that the world of CPAN was not quite as void and without form before you entered it as you make it out to be, and that you did not cast as much light into it as you believe.

Maybe someone would have written it if I hadn't, but history doesn't support these kinds of experiments. (Though nice Biblical strawman, by the way. If you're going to put words in my mouth, poetic license helps.)

Re:Things haven't improved much.

[murr]

I assume you're talking about Test::MockObject.

You keep making faulty assumptions...

Ah I see, I had overlooked the fact that you wrote Test::Builder as well. That one does seem to be very widely used - nice job!

I submit that the world of CPAN was not quite as void and without form before you entered it as you make it out to be, and that you did not cast as much light into it as you believe.

I stand corrected regarding the second part of my statement - Test::Builder IS widely used. Still, I can assure you that even Perl 4 came with a sizeable set of unit tests.

Maybe someone would have written it if I hadn't

Maybe YOU would have written it for Perl 5 anyway, even if there hadn't been a Perl 6 project? The last few years have seen a proliferation of unit testing libraries in all languages, and in most of them, Extreme/Agile Programming seems to have had more to do with it than Perl 6.

Though nice Biblical strawman, by the way.

Thanks! I strive to steal from the best.

Re:Things haven't improved much.

[Abcd1234]

But, as any truly funny joke, it has a kernel of truth to it: Perl 6 has been in development since forever, and in fact I can't remember any project of similar magnitude and visibility that has been delayed for so long (feel free to educate me, tho).

Well that's an easy one: Mozilla.

Re:quality and libraries, but quality of libraries

[belmolis]

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), where it is labeled as such, and don't present a full package until it is reasonably mature.

Future of scripting langauges

[xpuppykickerx]

What did they use to code the Matrix?

Re:Future of scripting langauges

[Creepy Crawler]

Shaper.

Specifically designed to create a digital consciousness from a seed value of 700MB (the amount of data held within our human DNA).

Re:Future of scripting langauges

[Tweenk]

Machine code - why would machines need English-like dialects instead of using their mother tongue?

Re:Future of scripting langauges

[Tumbleweed]

What did they use to code the Matrix?

64-bit asm, carbon unit. Suck it.

Re:future of perl?

[khellendros1984]

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.

Scripting language performance

[tcopeland]

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 to prevent rcov segfaults. It doesn't fix the root problem, but it's a start.

Re:Scripting language performance

[shutdown -p now]

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.

It's also about proper threading support, something that so many "scripting" languages still sorely lack, unfortunately, with giant lock-based interpreter designs etc.

Re:Scripting language performance

[tcopeland]

> It's also about proper threading support, something that so many
> "scripting" languages still sorely lack, unfortunately,
> with giant lock-based interpreter designs etc.

Yup, so they fall back on thread-per-process models, which works, but is quite a pain.

Glaring Omission: Groovy

[kimanaw]

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.

Re:Glaring Omission: Groovy

[Esther Schindler]

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:Glaring Omission: Groovy

[TimHunter]

http://www.lua.org/

Re:Glaring Omission: Groovy

[RichDice]

Didn't appear _anywhere_ in the article?

To quote me: "A segment of Java programmers seem to be embracing Ruby (and Rails) in particular. A new dynamic language, Groovy, is capitalizing on this trend by providing a dynamic language on the Java Virtual Machine (JVM) that incorporates elements of both Java and Ruby."

I admit it's not much, but you're the one who used the categorical.

Cheers,
  - Richard

Re:Glaring Omission: Groovy

[kimanaw]

Doh! Mea culpa...I guess 4 pages of CIO.com clutter left me cross eyed. Or maybe its the holiday weekend Friday afternoon.

(Note to self: use Edit->Find... before commenting)

But I still think its important enough to deserve more than a single passing comment.

Re:Glaring Omission: Groovy

[Foresto]

I wouldn't be surprised to see Python and Ruby supplanted by Groovy in a couple of years.

I would be surprised. Java's syntax is not its only shortcoming. :)

Re:Glaring Omission: Groovy

[LynnG]

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

Re:Glaring Omission: Groovy

[Bazouel]

What about LUA ? I see it used quite frequently.

Re:Glaring Omission: Groovy

[GaryOlson]

Do you consider political rhetoric dynamic? It's definitely scripted; but I don't know if it has enough structure to provide consistent results.

Re:Glaring Omission: Groovy

[DrEasy]

Groovy did appear in the article. p2, parag 4.

Re:Glaring Omission: Groovy

[nebosuke]

I would also look at Scala. Shares Groovy's strength of transparent Java interoperability, but opts for a radical departure in language design and concepts (for the better, IMHO).

Re:Glaring Omission: Groovy

[Esther Schindler]

Groovy. Check. Lua. Check. Scala. Good suggestion.

Political rhetoric? Sure, it's definitely scripted, the syntax has lots of boundary conditions, and it is well understood in its own domain. But it never actually executes any functionality so I don't think I should include it.

Seriously, those are good suggestions. one more, and I'd have a nice short-and-sweet article with which I could bonk the PTBs on their heads—Esther (who also blogs occasionally)

Re:Glaring Omission: Groovy

[fostandy]

Hmm, I can see an argument for sticking purely to the same languages as before... but not if you have a title which contains 'The State of the Scripting Universe'. This alludes to being definitive on a most basic level.

I never read the original article (the three year old one) so maybe I am missing some context. Groovy et al.* certainly don't have anywhere near as much takeup as the well established big players, but I think they still merit a paragraph or two's mention in an 'Up and Comers' section.

*See also: Beanshell and C# Script (this last one is touch and go, but I think the comments make it clear that the delineation between a scripting and non-scripting language is becoming less clear) and many others I don't know about - I read articles like this to find out!

Re:Glaring Omission: Groovy

[Esther Schindler]

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

[adpe]

Python has been my language for years. The pure beauty of the language together with the huge library did it for me. Plus, it's very easy to program python. Seriously. Just today, I've implemented an algorithm with a long, long loop and a lot of arithmetic operations. Python took 5:30 where Java took 10 secs. I'm serious, Python is SLOW, and last time I've checked, Ruby is even worse. (Interesting sidenote: C++ took 11 secs). I seriously love scipting languages, but the speed it horrifying. I'll stick to Java for a while.

Re:Good timing

[Ragzouken]

Have you tried Psyco? If Psyco doesn't work, rewrite the intensive parts in C.

Re:Good timing

[Anonymous Coward]

For such problems, Cython ( http://cython.org/ ) is really nice.

Re:Good timing

[Terrasque]

I too really recommend trying out psyco if your python code take a long time to execute.

From the page:

Benefits

        2x to 100x speed-ups, typically 4x, with an unmodified Python interpreter and unmodified source code, just a dynamically loadable C extension module.

Drawbacks

        Psyco currently uses a lot of memory. It only runs on Intel 386-compatible processors (under any OS) right now. There are some subtle semantic differences (i.e. bugs) with the way Python works; they should not be apparent in most programs.

In one situation where I had a lot of loops running the execution time went from a bit over 5 minutes, to 10-15 seconds.

Re:Good timing

[moderatorrater]

I had something similar happen to me. I've been driving my Honda Civic for years now, and it's always done well for me. However, just the other day I tried to drive across the country, and it took a lot longer than an airplane.

I love cars, but their speed is horrifying. I'll stick to flying for a while.

Re:Good timing

[sciurus0]

Also nice is the ability to inline C with Weave.

Osborne

[XanC]

You're recalling the Osborne Effect. I sure hope that doesn't befall Perl.

Re:Osborne

[Just Some Guy]

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

[ThePhilips]

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.

Re:Osborne

[VGPowerlord]

Speaking of Perl 5, Perl 6, and .NET...

Is it just me or does Perl 6 feel an awful lot like VB.NET? Taking a language that's good enough for what it was used for, making just enough arbitrary syntax changes that you need to re-learn it, and requiring a VM to run it. The only difference being that Perl 6 can still run Perl 5 code. Of course, why you'd need Perl 6 to run Perl 5 code seeing as Perl 5 runs Perl 5 code perfectly well...

Re:Osborne

[chromatic]

Is it just me or does Perl 6 feel an awful lot like VB.NET?

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.

Taking a language that's good enough for what it was used for, making just enough arbitrary syntax changes that you need to re-learn it, and requiring a VM to run it.

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.

Of course, why you'd need Perl 6 to run Perl 5 code seeing as Perl 5 runs Perl 5 code perfectly well...

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:Osborne

[SanityInAnarchy]

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:Osborne

[chromatic]

Since that's "nothing", so far, it's pretty much vaporware.

That statement is wrong (or if it's right, then Ruby 2 and Python 3000 and PHP 6 and Java 7 and GHC 6.10 and so on are all vaporware too.)

Re:Osborne

[daveime]

Have not tried Perl6, I guess the main reason being the syntax changes.

I'd read somewhere that the concatenation operator was being changed from a . (dot) to a _ (underscore).

That is just plain ludicrous, as Perl5 variable names such as $my_thing = 1 now means something completely different under Perl6.

I'll stick with my Perl5, it's served me well for the past 8 years thanks.

Re:Osborne

[chromatic]

That is just plain ludicrous, as [Perl 5] variable names such as $my_thing = 1 now means something completely different under [Perl 6].

The concatenation operator is now ~ (which is a further improvement because now the tilde signals stringy behavior in all sorts of contexts) -- but what you said was untrue even when the underscore was the string concatenation operator. As there are no (undeclared) barewords in Perl 6, there's no way to parse $my_thing as anything other than a variable name.

Re:Osborne

[HiThere]

Not sure about the others, but Python 3000 *IS* vaporware, and intentionally so. Python 3.0 is on track to be released this October. (A beta is available for current download. It's still missing a lot of external libraries, however, as it's got some reasonably sized incompatibilities with the 2.x series.)

Re:Osborne

[shutdown -p now]

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.

MCSD.NET/MCPD here. I wonder why JScript.NET - which is essentially an implementation of an early draft of ES4 - is one of the officially supported Microsoft .NET languages ever since VS2003, then, and comes with everything that's needed to embed it into your programs (or just quickly whip up scripts calling .NET APIs). You know, they've even got JS.NET declarations and samples on MSDN for most APIs. Then of course there's IronPython (1.0 release a while ago, 2.0 to follow soon) and IronRuby, both Microsoft projects, and heavily hyped now for Silverlight. And C# 4.0 is going to have opt-in duck typing for property/method calls. Oh yes, we are sooo brainwashed here...

Re:Osborne

[daveime]

So trying to concatenate the variable $my with a possible file handle called thing is okay now ?

Re:Osborne

[chromatic]

Unless you change the Perl 6 grammar, $my_thing gets parsed as a variable name, not string concatenation. (You'd have to override the grammar to change allowed characters in identifiers, whitespace sensitivity, the concatenation operator, and filehandles.) You can do it, but that's not how the Perl 6 grammar works.

Re:future of perl?

[SanityInAnarchy]

Pffft, Perl is perfectly good for anything that needs string manipulation and such.

Unfortunately for Perl, so is Python.

(Well, and Ruby. I'm partial to Ruby, but there's no XKCD for me to link to.)

Forgot some important ones

[vlad_petric]

Brainf*k | yes

LOLCode | yes

Turing machine descriptions | yes

Jaxer

[m3rr]

• Client-side only

Clearly you haven't heard of Jaxer.

Re:Jaxer

[hobo sapiens]

Have you used Jaxer?

I have used it a bit, mostly just for experiments. It seems really nice. Unlike many attempts to use Javascript on the server (looking at you ASP) it actually works just like javascript works in the browser. It even uses the javascript engine from Mozilla. Oh, and this means you can use you favorite javascript libraries (like prototype!) on the server too. Very cool concept.

The only concern I have is scalability, though. Seems nice for a small website, but I don't know about how well it'd hold up under a real load.

Re:Jaxer

[m3rr]

Like you, I've only played around with it. I love it so far and it works great with jQuery. It would be nice to see some benchmarks and get a feel for how it performs under load, though.

Re:future of perl?

[DragonWriter]

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.

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.

It's really just a problem...

[an.echte.trilingue]

I really like DHTML + JS + CSS for dynamic content. I downright love CSS; it takes time to learn, but it is just awsome. It's really just a problem of getting browser vendors to support a cross-platform standard for the DOM tree (I think we all know who I am talking about). Even with the mess that we have now, js libraries like prototype.js and mochikit have done a pretty good job of abstracting the browser quirks out of our code and given us a means to develop quality, working web applications quickly and easily.

Or, you could scrap all this progress and start over on a new standard. Good luck with that.

Re:quality and libraries, but quality of libraries

[Abcd1234]

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.

Javascript Works Well for Telephony Too

[anthm]

Several years ago I wrote a javascript module for Asterisk open source PBX
More recently I added it for my own project FreeSWITCH ( http://www.freeswitch.org/ )

We actually also support LUA, Python, Perl, JAVA and MONO as ways to script telephony apps.

It's quickly becoming a great new way to prototype and deploy audio driven apps for your phone system.

PHP And Perl

[MattW]

PHP and Perl don't really deserve to be labeled "scripting languages" in my head either any more. PHP has had growing object oriented capabilities for ages - PHP 5.3a1 even got lambdas w/ closures. PHP is a fairly great language; it got a bad rap due to the way it enabled horrible security practices so well in the PHP3 days. I think I prefer Python/Django due to the more expressive syntax and superior templating, but PHP is good and getting better. Is it dynamically interpreted? Sure, but you can use bytecode caching to save compiled copies. Likewise, Perl may be suitable for use as a scripting language, but it has obviously become a lot more.

Re:PHP And Perl

[init100]

I think I prefer Python/Django due to the more expressive syntax and superior templating

I never tried Django, but did you try the PHP template engine Smarty? It is the best templating engine for PHP that I've come across.

Re:PHP And Perl

[MattW]

Yes, I've used Smarty. It's not bad, but if you try Django, you'll probably like it better. At least, syntactically speaking, I enjoy typing up Django templates quite a bit more.

Re:Python

[Tweenk]

I think it's the other way around. It has a lot of bindings, programs are shipped as source, and it has many conveniences, which makes it a scripting language - which incidentally is powerful enough to do application development.

There are few languages in modern use that are not object-oriented (I can only think of C and Fortran in their respective niches), so it's not a sign of not being a scripting language.

Another Perspective on Dynamic Languages

[kimanaw]

Dynamic Languages Jobs Barometer

objC?

[MattW]

I'm not sure what you're sick of with C++, but I've been writing objC lately for the iphone, and I'm definitely enjoying it a lot more than I ever enjoyed c++. (Although that may be just because I like Apple's nextstep object hierarchy more that I ever liked the c++ libs)

Re:quality and libraries, but quality of libraries

[arodland]

Of course there's a lot of crap on CPAN. But there's also a lot of really good stuff, and there are tools to help you find the best of the good stuff. Besides which, having someone else's complete and utter crap to work with can still give you a head start compared to doing everything from scratch. Not to mention, in one-off projects you can sometimes just use the utter crap, get the job done, and not have to tell anyone.

In my honest opinion...

[houbou]

I think the W3C should evolve the scripting area to recognize and have UI/App components in the language. Mesh CSS/DOM/JavaScript/Ajax along with accessibility and usability as a new toolkit and standard. That's why Dojo and the likes are so popular. If the W3C evolved the scripting/development toolkit for that, it would make sense to me.

Re:future of perl?

[Tassach]

Neither Python nor Ruby have a code repository with the depth and breadth of CPAN. Rubygems has promise, but CPAN has at least a 10 year head start on it.

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.

Documentation

[prollifik]

A good browseable documentation. CHM rules.

Scripting on .NET

[Tetsujin]

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:Scripting on .NET

[FishWithAHammer]

My impression was that .NET had a lot to offer for users of Unix scripting languages

Pretty much, yeah. The integration still has some warts, but the Dynamic Language Runtime (additions to Mono and .NET alike) will help with those considerably.

The post you replied to is just clueless.

Re:Ruby/schmuby

[Abcd1234]

I thought Perl had full Unicode support... is there something in particular in it's implementation that you feel is missing (I've never had to work with Unicode, so I honestly don't know)?

Lexicography as identity

[Tetsujin]

You are quite right. But it still applies to evil creatures like PHP.

Damn straight...

I have serious doubts about the usefulness of this kind of language feature, compared to its painful consequences...

Re:What about real languages?

[metamatic]

When are we going to get a new high-performance, clean, simple, meta-programmable, incrementally-compilable language to replace C++ with?

Java?

Everyone is focused on these dynamic languages with JITs and bloated runtimes and garbage collectors. They may give decent performance if you can arrange a suitably ideal environment for them to run in. We can't use them for game engines, though.

I beg to differ.

Re:future of perl?

[VGPowerlord]

Neither Python nor Ruby have a code repository with the depth and breadth of CPAN. Rubygems has promise, but CPAN has at least a 10 year head start on it.

Can Perl 6 access Perl 5 modules while in Perl 6 mode? If not, CPAN for Perl 6 is behind by several years.

In defense of what I consider a bad idea...

[Tetsujin]

I think this makes a certain amount of sense when 99% of what you're doing is dealing with text (command-line arguments, form input on the web, database queries, whatever) - it makes it very convenient to deal with text in terms of the usual meaning applied to that text, and apply your results back to a textual context without a separate operation.

I don't particularly like this in general - but I would say that I'm not prepared to write it off entirely...

All of this was done in LISP in the 70s

[Anonymous Coward]

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:All of this was done in LISP in the 70s

[Anonymous Coward]

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.

Re:All of this was done in LISP in the 70s

[shutdown -p now]

Such is life. It doesn't matter who is really the first to do something, it only matters who is the first to successfully market it.

Re:All of this was done in LISP in the 70s

[DavidHumus]

and APL in the 60s.

Incrementing filenames...

[Tetsujin]

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"...

What about Cold Fusion?

[coryking]

Last I checked, it is none of those *and* it used to be the powerhouse behind killer Web 3.0 sites like MySpace and FuckedCompany*.

*IIRC.

Re:future of perl?

[init100]

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?

Mumps - an often overlooked scripting language

[kcokane]

An often overlooked scripting language is Mumps (Massachusetts General Hospital Utility Multi-Programming System), developed in the late 1960's.

Mumps (also referred to as M) supports a multidimensional and hierarchical database facility implemented as string subscripted array references. It was widely used in clinical computing and remains to this day the basis of the U.S. Veterans Administration's computerized medical record system, the largest of its kind in the world.

Its main features are: (1) its tree-structured (multi-dimensional) database; and (2) its flexible string handling facilities which now including PCRE functions.

There are both compiler and interpreter versions available as open source/GPL packages. It supports many text processing functions, system shell integration, as well relational database access. There is also a compatible C++ library to integrate the tree structured data base access into C++ programs. The Mumps/II native hierarchical array database may range in size up to 256 terabytes.

The package is available from:

http://www.cs.uni.edu/~okane

(see download link).

Re:Mumps - an often overlooked scripting language

[Hemogoblin]

An often overlooked scripting language is Mumps...

Hiss! It burns!

MUMPS (originally, Massachusetts General Hospital Utility Multi-Programming System) is conceptually different from just about every other programming language out there. The primary design goal MUMPS was to create code that, once written, can never be maintained by anyone ever again. The syntax is somewhat reminiscent of FORTRAN and SNOBOL (no, not the toilet cleaner), only much, much worse. Ironically, being inflicted with mumps (the disease) is much more pleasant that actually working with MUMPS (the language). A more apt name for the language certainly would have been EXPLOSIVE-DIARRHEA; Im sure they could have even worked SNOBOL (the language, or, heck, even the toilet cleaner) in there as well. ...

Keep in mind that MUMPS is not one of those esoteric joke languages. It should be, but it isnt. MUMPS is very real, and has been used for the past thirty years to create and maintain colossal medical information systems.

- http://thedailywtf.com/Articles/A_Case_of_the_MUMPS.aspx

Re:Mumps - an often overlooked scripting language

[Just Some Guy]

An often overlooked scripting language is Mumps (Massachusetts General Hospital Utility Multi-Programming System), developed in the late 1960's.

I would rather hack APL than M, and that is not meant as a compliment to either language.

Re:Mumps - an often overlooked scripting language

[kcokane]

APL has no data base. And I knew Ken Iverson,
he was a pretty sharp comp sci'tst.

Re:Mumps - an often overlooked scripting language

[kcokane]

http://www.cs.uni.edu/~okane/source/ISR/isr.html

na-na-nana!

Re:Mumps - an often overlooked scripting language

[shutdown -p now]

An often overlooked scripting language is Mumps

Yes, and an often overlooked object-oriented language is COBOL. Wonder why...

They suck because their toolage sucks

[coryking]

Only Perl can read perl. You can forget about a fancy IDE with intellisense when you use perl.

PHP support means generating a wordlist that would wrap from coast to coast.

Ruby? Dunno.. but like Perl and PHP since it is dynamically typed it is harder to write an IDE for it. Haven't seen what Microsoft has done for it yet.

Javascript? Really depends on how well you can manage keeping your Javascript code in sync with your server code.

Re:What about real languages?

[coren2000]

When are we going to get a new high-performance, clean, simple, meta-programmable, incrementally-compilable language to replace C++ with?

Java?

Going for a +5 funny IC.

Re:Ruby/schmuby

[coryking]

Why are single-byte chars even possible in this day and age in the context of a string?

Because the old grampa C coders really, really like hand-optimized pointer arithmetic*. That and 8 bits is enough for any language blessed by the queen.

*course, if you use wchar you could do the same pointer arithmetic as before.

Re:future of perl?

[Just Some Guy]

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:quality and libraries, but quality of libraries

[coryking]

CPAN is the best part and the worst part of Perl.

Ever tried to write a meta package in whatever build system you use (FreeBSD Ports /gentoo whatever/ RPM)? Especially when the ports tree doesn't have all the CPAN modules?

Talk about a mess! That said, you only really have to do it once and then maintain your meta package.

Re:future of perl?

[SanityInAnarchy]

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?

[Abcd1234]

Can Perl 6 access Perl 5 modules while in Perl 6 mode?

Yes, Perl 6 will be able to use Perl 5 packages.

What about Lua?

[hh10k]

Lua's said to be the number 1 scripting language for making games. Surely it deserves a mention.

Poor Lua never gets the respect it deserves.

Re:What about Lua?

[Abcd1234]

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).

Ruby has a builtin type for Regexp

[Safiire Arrowny]

Ruby example:

>> puts 'yep' if 'I like cats' =~ /\w+ \w+ \w+/
yep

or:

>> "I like cats".match(/\w+ \w+ (\w+)$/).captures
=> ["cats"]

You can create a union of two regexp:
>> Regexp.union(/I like \w+/,/sandwhiches$/)
=> -mix:I like w-mix:sandwhiches

Also they are Perl compatible.

Ignoring the 800 pound gorilla...

[Anonymous Coward]

So, no interview with Mike Cowlishaw, the developer of Rexx? Ignoring Rexx, Object Rexx and NetRexx?
I thought this was about scripting languages.
And NASA alone having MILLIONS of lines of Rexx code.
I've coded Rexx on IBM CP/CMS, Amiga, and Linux.
And the Amiga version is better than what is available for Linux.

Rexx; everything is a string, and math is decimal based, with 15 digits of precision.

Re:Ignoring the 800 pound gorilla...

[Esther Schindler]

My dear Anonymous:

<snort>

Perhaps you should take a closer look at your copy of Down to Earth REXX. Why yes, that is "Schindler" on the front cover.

As was explained earlier, Lynn and I chose these languages because that's what we had chosen three years ago. And we chose those at the time because they had the highest usage in the Evans Data surveys.

Re:Python

[francium de neobie]

It is possible to ship a Python program in its "compiled" form (i.e. .pyc files), many Python-based BitTorrent clients do that. The distinction between scripting language and programming language these days are blurring. Just like compiled vs. interpreted languages.

Script languages as glue

[the_arrow]

This part from the old TFA cought my eye:

Conway: Very simply, they're the glue that holds complex systems together. They allow developers to hook together commercial and open source software packages, and to coordinate the resulting systems.

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:Script languages as glue

[Just Some Guy]

Oh, lovely ARexx - the most hideous and fun of languages. For those not in the know, it was common for Amiga programs to have "ARexx ports", which were basically ABI hooks where you could call any of a number of that program's internal functions. The cool thing was that once you'd "addressed" a running program, you could call its functions just like any other ARexx function. For example:

address BACKUPPROGRAM
new backup
add /home
add /usr
add /var
results = dobackup
address EMAILPROGRAM
new email
subject "backup results"
to "me@example.com"
body results
send

It's been 10 years since I've really messed with it, so the syntax is almost certainly wrong, but you get the idea.

The coolest thing about ARexx was finding new and weird ways to bind programs together. I wrote a script to link an FTP program and a graphics program (ImageFX?), so that the progress bar was rendered as a bolt of photorealistic lightning that started in one corner of the screen and stretched to the other as the download continued. This certainly wasn't the most useful of hacks, but it was fun and took less than a half page of code.

Re:Under the table

[fuzzix]

It's a game sailors play.

You need a few drinking buddies, a long banquet table with a long, heavy tablecloth, and one prostitute.

The idea is to sit at the table while the hooker(who is under the table) will chose one of the men at random and begin sucking his dick.

The object of the game is to receive fellatio and come without making it known to the other guys. For example, if the hooker chooses you and you squirm or grunt whilst having your dick sucked, and one of the guys calls you on it, then you lose and you have to buy the next round of beers before the hooker chooses another man at random.

It's a game GNU/Linux users play.

You need a few drinking buddies, a long banquet table with a long, heavy tablecloth, and one Vista lappy.

The idea is to sit at the table while the Windows box with Crysis (which is under the table) is passed to one of the men at random and they begin playing.

The object of the game is to play the game and win without making it known to the other guys. For example, if the game chooses you and you squirm or grunt whilst playing Crysis and one of the guys calls you on it, then you lose and you have to buy the next round of beers before the game chooses another man at random.

Re:Ruby/schmuby

[Greenmoon]

Not a single one does Unicode properly.

Perl handles Unicode just fine (since 5.6, that is).

Re:future of perl?

[piojo]

Pffft, Perl is perfectly good for anything that needs string manipulation and such.

Unfortunately for Perl, so is Python.

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:
if ($str =~ /(.*)@/) { print $1; }

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:future of perl?

[lpq]

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:Python

[thogard]

Does being object-oriented help? I look at the quality of the code written in C and I look at the quality of code the comes from pseudo OO languages (C++, Python, C#) and it is not up to the same standard. It seems to me that OOD hasn't help up to the ease of use that its proponents have been pushing for the last few decades since it seems to lure developers into a false sense of architecture scale.

Re:quality and libraries, but quality of libraries

[rmelton]

According to the coverity report http://scan.coverity.com/rung2.html Perl does not have the lowest defect rate.

Re:future of perl?

[kcelery]

The difference is, it will be much easier to write a python in perl 6 then a perl 6 in python.

Re:future of perl?

[kcelery]

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:future of perl?

[Timex]

I write perl and bash more often than not.

I'm learning Ruby, even though it's Verboten for use at my place of employment. (It's not guaranteed to be installed on any particular server, and it's probably intentionally removed if it's part of the OS install.)

If I need QnD string manipulation, I use perl. I haven't touched Python since about 1999.

Perl is nicer than many

[melted]

But even perl chokes badly on "invalid" chars, and there's no way that I could find to just replace them with question marks or just pass them around unchanged. I work with terabytes of text and this text comes from the web, blogs and other sources. It is pretty much guaranteed to have broken chars in it, and I don't want to throw away a line of text just because one character is not an "approved" Unicode code point.

Python is pretty busted - I gave up on it after trying to write a scraper in it (using BeautifulSoup). I'd need to fix _standard libraries_ to make it not crash every now and then, and I'm spoiled - I expect the libraries that come in the RPM to just work. Ruby doesn't even know what this Unicode thing is.

Re:future of perl?

[junklight]

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:Perl, Perl, Perl, Perl, Perl... â" dying!

[chromatic]

Am I missing something?

Facts, for one. No one who's tried to reproduce TIOBE's data has succeeded. Unreproducible statistics are suspect.

Re:future of perl?

[gnud]

Well, I don't have much experience with CPAN. But my experience with python is that I find out what library I need online, and then install it with easy_install.

Re:future of perl?

[Anonymous Coward]

import re

reg = re.compile('.*@')
m = reg.search(string)
print( m.group() )

Re:future of perl?

[owlstead]

"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:future of perl?

[PiSkyHi]

Python's current wave of popularity will make it handy to know when you want to use someone else's code, but everytime I encounter someone else's Python, it only runs on version X.
It's a pain to be a Python admin, its just simplicity to do so for Perl 5.
All this talk of Perl 5 and 6 - the lifespan of a Perl 5 script is probably amongst the best of all languages in terms of major distro's providing an interpreter that still runs the old code base.
Python is going through evolution, a little too much for my liking to be effective. That and many Python programmer's still can't decide how to treat a list of 1 element.
If you already think in Perl, Python is wasted effort.

Re:future of perl?

[julesh]

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:future of perl?

[Just Some Guy]

Even then, "string =~ s/foo/bar/" isn't inherently better than "string = re.replace('foo', 'bar', string)". It's slightly less typing, but since Python's using Perl's RE engine, there's no difference in actual functionality.

Some argue that Java's typing is not enough...

[Sits]

... and that since it's not rigourous enough we should be using other languages like Scala. If Java's type system IS enough (but incomplete) then the argument goes why should dynamically typed languages be singled out for not being robust enough on bigger code bases? I'm paraphrasing from the Static Typing's Paper Tigers section of Steve Yegge's Rhino's and Tigers blog post though.

I doubt that dynamic languages slowness would be solved (today without new research) if they switched to static typing though... Surely dynamic languages could target VMs like the JVM or CLR and that may ultimately lead them to running just as fast as Java or C#? If that were the case the speed problem would not be down to their dynamic nature but perhaps something like the lack of extensive JITing...

Re:Some argue that Java's typing is not enough...

[IamTheRealMike]

Oh sure, I would never argue that Java has a good type system. Even C++ has a better type system than Java. More exotic languages like Haskell or even Epigram show some of the things you can do with advanced type systems, but as a good middle ground I'd like to be using D.

The slowness of dynamically typed languages is (today) pretty fundamental. Static typing allows you to make a lot of decisions at compile time, but for a dynamic language all those decisions have to be made on the fly because almost any assumption you make can be invalidated at any point. There have been some interesting research projects into solving this problem, for instance Psyco for Python, but they usually trade off memory against CPU time. In other words you still pay the piper, just in a different way.

Re:Some argue that Java's typing is not enough...

[Raenex]

If Java's type system IS enough (but incomplete) then the argument goes why should dynamically typed languages be singled out for not being robust enough on bigger code bases?

It's called a continuum. Java's mediocre static typing is better than the complete lack of static typing on dynamic languages. Being able to use see types is a huge benefit. As for finding bugs with testing, it's much faster to find them while you're typing. Code completion is extremely productive.

Yeah, occasionally static types get in the way, but overall I find them too useful to do without.

I'm paraphrasing from the Static Typing's Paper Tigers section of Steve Yegge's Rhino's and Tigers blog post though.

Steve Yegge is a big blowhard.

Thanks for following up here

[Sits]

While Slashdot might not be the place that company movers and shakers read, it's interesting to follow your replies and justifications for the article here (and of course it has encouraged me to read the article itself).

Re:Thanks for following up here

[Esther Schindler]

Thanks for the kind words!

But I must respectfully disagree; there are plenty of movers and shakers here. In intelligently run companies (and one of the joys of me working at CIO.com is that I've discovered that they do exist!) the Powers That Be to want to know what the techies think. Sometimes they even listen to the advice. As with so many other things, the people who believe they have the power may not have as much as they think they do... and vice versa.

Re:future of perl?

[SanityInAnarchy]

Given that your comment predates mine, I'm pretty much assuming that the progression was like this:

Guy likes Lisp, because it's elegant.

Guy finds that Perl gets stuff done, but it's a lot uglier.

Guy finds that Python gets stuff done faster and more easily than Perl, and isn't as ugly. Nowhere near as beautiful as Lisp, though.

Re:future of perl?

[SanityInAnarchy]

Neither Python nor Ruby have a code repository with the depth and breadth of CPAN. Rubygems has promise, but CPAN has at least a 10 year head start on it.

Depth and breadth means nothing at all when I can find exactly what I need in Rubygems.

It's a bit like Google. What do I care what the other few hundred million (or billion) results are? I'm probably not going to read past the first page.

...more mature and IMHO more productive.

I would agree with you, but only because of CPAN. And given the above...

No, I don't think Perl is "write-only", and I know it isn't horrible. I know it's possible to write ugly Ruby code.

I do, however, find that on the occasion I have to do more than simply glue components together -- that is, when I have to actually write something new -- I can do so much more easily in Ruby than in Perl.

Re:future of perl?

[SanityInAnarchy]

That's because you don't have to use @_ or shift. Perl can support named parameters, optional parameters,

Really? I've never seen it, not directly. All I ever see is:

my ($arg1, $arg2, $arg3) = @_;

Or:

my $params = shift;
if ($params->{whatever}) { ... }

Does it have more than this?

I do know that with Ruby, I can specify a "splat" argument, or I can use the positional arguments directly. And with Javascript, I can either use positional arguments, or the "arguments" array, or both. But Perl only ever seemed to support @_.

I'm sure the CPAN has modules for all this.

Ah. That explains it.

It's interesting how that works -- when a language like Perl stagnates, people extend it with modules. Not necessarily bad, just strange.

Re:future of perl?

[renoX]

>However, Perl5 does suck, compared to Ruby or Python. Perl6 looks very, very good -- but is nowhere near ready.

Frankly, I think that Perl6 only looks good to Perl lovers, myself I think that it still looks like noise different noise from Perl5 but still hard to read and to maintain.

For beginners, there's Python, for advanced users who know already know shell or Perl5 and are not satisfied with it there's Ruby..

Re:future of perl?

[SanityInAnarchy]

myself I think that it still looks like noise different noise from Perl5 but still hard to read and to maintain.

One of the features of Perl6 that I really like is custom syntax. That helps a lot.

I like a lot of Ruby syntax, some of it Perl-inspired -- the optional brackets are beautiful. I like Python's indentation, and if I could, I'd probably be using Lazibi in Ruby. I like Javascript's object notation, and its treating of hashes as objects.

A lot of these, though, are mostly cosmetic. Certainly it's possible to abuse things, but by making the syntax separate, it means we can stop arguing about what syntax makes a good language, and start focusing on other features.

For beginners, there's Python,

I don't know, I've yet to see an environment beat Try Ruby for sheer beginner accessibility.

Re:future of perl?

[HiThere]

Ruby's nice, but it's slow compared to Python. If you're doing something where that doesn't matter, then Ruby's a nice choice.

Also, Ruby's libraries seem to be more specialized towards web development than Python's. This may well make Ruby a better choice for that area. But they are (or were) much weaker in more general areas. So again, it depends on what you're doing.

Re:future of perl?

[chromatic]

[When] a language like Perl stagnates, people extend it with modules. Not necessarily bad, just strange.

I'm not sure "stagnates" is fair; one of the design goals of Perl 5 was to enable language experimentation and extension in modules. 14 years (and some 14,000 distributions on the CPAN) later, there are some successes.

Um, major missing option

[savuporo]

LUA. Just check out how many major apps and games have selected Lua as their scripting language due to lightweight runtime, ease of integration and relative speed.

Re:future of perl?

[holdenweb]

"""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."""

I'm a Python user myself, just because the language happens to fit better with my temperament and preconceptions, but I used Perl fairly extensively in the early days of the wild, wild web, and I do get a little tired of the users of one language knocking other languages unnecessarily.

In Iceland this week, a Python User Group member who has a large web site written in Perl asked me "Why should I rewrite my web site in Python?". I couldn't think of a single reason, as long as the site is doing what it needs to. Perl is a workhorse language, and will likely continue to be so.

I *do* think Python has advantages as a first programming language but, as Tassach observes, an experienced programmer will get the best out of whatever language they use by adopting disciplines that make up for its shortcomings. We sometimes jokingly refer to Perl as a "write-only" language, but that could also be construed as a compliment about its terseness. A good Perl programmer with a familiar toolkit at their fingertips can cut code at high speed, and the problem of understanding six months later what it does is eased by simple documentary comments.

Re:future of perl?

[SanityInAnarchy]

Ruby's nice, but it's slow compared to Python. If you're doing something where that doesn't matter, then Ruby's a nice choice.

If I'm doing something where that does matter, I'll write C extensions to do the heavy lifting, or I'll write the whole thing in C/C++.

And for that matter, all my personal projects target the experimental Ruby 1.9, which beats Python in a few benchmarks.

Also, Ruby's libraries seem to be more specialized towards web development than Python's.

Maybe. I haven't tried to do much else with it for awhile -- though I frequently see and hear of other projects.

Then again, the closest thing Python has to a package management system... EasyInstall sucks. So how am I going to get ahold of those other Python libraries in the first place?

And the main reason I use Ruby is, if I end up having to write these libraries myself, it won't be too painful. I think it wouldn't be nearly as much fun to try that in Python.

Re:future of perl?

[HiThere]

FWIW, I've had no trouble with getting and installing Python libraries. Most of the ones that I need come included with Python.

OTOH, if I *really* need speed, then I agree with you, a native compiled language is the way to go. Because of library availability that usually means C or C++, though I'd rather use a language with decent syntax and garbage collection, like D. No libraries for that, though.

Python is my choice for the intermediate position. It's got much of the desirable language feature of an interpreted language, and it's only around 5-10 times as slow as C. (Just how much depends on how much your code is using native libraries.)

Re:What about real languages?

[shutdown -p now]

When are we going to get a new high-performance, clean, simple, meta-programmable, incrementally-compilable language to replace C++ with?

Well, since you didn't put static typing on the list, what you want is called Common Lisp, and it's been out in the wild for quite a while.

If that was just an accidential omission, I suggest that you have a look at Fortress. On the other hand, with the introduction of concepts, constexpr, basic type inference, lambdas, and some other syntactic and semantic improvements, C++0x might also be good enough.

Javascript

[weston]

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.

Why? After experimenting and then writing real applications in it, I really quite like the object model, and find the language most expressive and flexible thing I've really written anything in (C, C++, Java, Perl, PHP), so much so that I'm fearing the introduction of classes, even though it has some good reasons, is going to turn the language into a middle-morass ghetto like Java.

Too much use is made of "eval"

An over-used feature in a language is one of the easiest problems to address.

Because of this, Javascript has scaling problems.

Scoping and namespace collision issues are real, but there are pretty ready techniques for dealing with them. Scaling really only becomes a problem when you need to bring together two codebases written by programmers who didn't use those techniques.

There are definitely other security and other implementation issues, but increasingly, I'm finding that unless I need rich media features for which something else is more appropriate, I actually *prefer* working in Javascript.

Re:future of perl?

[SanityInAnarchy]

Python is my choice for the intermediate position.

I guess that's the part I don't get. What, exactly, is the intermediate position? What's a use case where Python's speed advantage actually matters, yet the speed advantage of something faster (like C) doesn't?

Re:future of perl?

[eddeye]

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?

Absolutely, use the best tool for the job. I used Perl for about 4-5 years. Did a lot of text processing, network programming, and system administration tasks with it. Some were throw away scripts, others stuck around for a while.

Then I picked up Python. Over the next year a funny thing happened. I began using Perl less and less. Python was just so easy and clean and structured. I didn't need cpan because the standard library did 98% of the job for me. As I learned more Python, it became the best tool for the job. Even quick throw away jobs. I stopped thinking about cryptic undeclared variables and tripping over $ @ % distinctions. Python just worked. Whenever a script morphed into something beyond it's original purpose, the transition was effortless. It's been about 4 years and I haven't looked back.

I didn't give up Perl because my toolbox was full. I gave it up because it's no longer the best tool for any job. YMMV.