Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Programming IT Technology

The State of Scripting Languages 415

Posted by ScuttleMonkey
from the coming-along-nicely dept.
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."
This discussion has been archived. No new comments can be posted.

The State of Scripting Languages

Comments Filter:
  • by Anonymous Coward
    Preemptive strike! You're a moron, and Java != Javascript!
    • 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"?

  • by PunkOfLinux (870955) <mewshi@mewshi.com> on Friday August 29, 2008 @04:16PM (#24801465) Homepage

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

  • by ilovesymbian (1341639) on Friday August 29, 2008 @04:23PM (#24801623)

    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.

    • by MightyMartian (840721) on Friday August 29, 2008 @04:25PM (#24801651) Journal

      I am getting more comfortable with Javascript, though I still think DHTML and CSS are fundamentally fucked, and it really is time, if this web delivery of apps thing is for real, to find some more rational means of actually dealing with dynamic content.

      • Re: (Score:3, Insightful)

        by clang_jangle (975789) *
        CSS is only "fundamentally fucked" because hardly anyone can be bothered to code CSS compliant web pages. It's a shame, really.
        • Re: (Score:3, Insightful)

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

        • Re: (Score:3, Interesting)

          by FLEB (312391)

          I think CSS has been stretched a fair bit farther than it ever should have been. It's not a layout language-- primarily, it's a text style description language-- but in the absence of anything better, we just have to keep on trying to figure out how to wedge the float mechanism into giving a decent multi-column layout (unless you want to play pixel-perfect with absolute positioning).

          That, and I'd have to say-- and I'm someone who works in CSS every day-- parts of the box model would probably qualify as "fun

      • by an.echte.trilingue (1063180) on Friday August 29, 2008 @05:24PM (#24802849) Homepage
        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.
      • by Crazy Taco (1083423) on Friday August 29, 2008 @07:52PM (#24804653)

        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.

        • by xero314 (722674) on Friday August 29, 2008 @11:56PM (#24806595)

          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.

          • by IamTheRealMike (537420) <mike@plan99.net> on Saturday August 30, 2008 @08:22AM (#24809491) Homepage

            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.

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

    • by Surt (22457) on Friday August 29, 2008 @04:28PM (#24801709) Homepage Journal

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

    • by grahamd0 (1129971) on Friday August 29, 2008 @04:34PM (#24801815)

      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
      • Cross-platorm

        Yes, but the problem is, most JavaScript has to be tested on Firefox, IE, Safari, Opera, Konqueror, etc. And most likely you will be rewriting code or removing features to make it work on IE or older versions of Safari, Opera, Konqueror, etc.

      • Jaxer (Score:2, Informative)

        by m3rr (669531)

        • Client-side only

        Clearly you haven't heard of Jaxer [aptana.com].

    • by serviscope_minor (664417) on Friday August 29, 2008 @04:42PM (#24801993) Journal

      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.

    • by Foofoobar (318279) on Friday August 29, 2008 @04:46PM (#24802079)
      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.
  • by serviscope_minor (664417) on Friday August 29, 2008 @04:28PM (#24801721) Journal

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

    As far as I can tell, it's a vaguly amorphous definition based on some notion of interpretedness, but C interpreters exist, for instance, and TCC can be used to run C "scripts".

    • Re: (Score:2, Insightful)

      by BitterOldGUy (1330491)

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

      As far as I can tell, it's a vaguly amorphous definition based on some notion of interpretedness, but C interpreters exist, for instance, and TCC can be used to run C "scripts".

      If it started out as a compiled programming language then it's not a scripting language.

      Scripting languages are for moving files around, administrative tasks and doing odd jobs.

      At least that's what it was in my day when we had to program in the snow uphill both ways and liked it!

    • Re: (Score:2, Informative)

      by Thought1 (1132989)
      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 [wikipedia.org], which isn't too bad.
    • by abigor (540274) on Friday August 29, 2008 @04:43PM (#24802003)

      Agreed, as Python, Ruby, etc. are compiled to byte code which run on virtual machines, just like Java...yet no one calls Java a scripting language. So I'm not sure either. Maybe it's "dynamically typed and either interpreted or runs on a virtual machine"?

      To be honest, Bash is one of the few 100% interpreted languages I know, and the only one I call a scripting language these days.

      • Re: (Score:2, Informative)

        by broken_chaos (1188549)

        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.

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

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

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

        • by abigor (540274)

          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.

      • by ToasterMonkey (467067) on Friday August 29, 2008 @05:59PM (#24803351) Homepage

        python - an interpreted, interactive, object-oriented programming language
        ruby - Interpreted object-oriented scripting language
        java - Java interpreter

        First of all, ruby's man page calls itself a scripting language, and secondly...
        #!/usr/bin/java
        println("Hello World!");

        Oh right...

        You can call all of these "interpreted" languages, but the ones with interactive prompts, or able to execute a source input file I throw at it, those are scripting languages. Java is nowhere NEAR a scripting language, it was not built for this. The other languages WERE built for this. It's an important distinction, and it doesn't make a perl/python/ruby developer any less of a man. Honestly, the interactive portion, and executing with #!/usr/bin/foo are the #1 and #2 indicators that it qualifies as "scripting".

        You almost sound like "scripting language" is derogatory. Well, it's not.
        Many people WANT scripting functionality for the Java platform, but it isn't here until I can run a one liner from the command line.

      • Re: (Score:3, Insightful)

        by zmooc (33175)

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

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

    • by Tweenk (1274968)

      My understanding of scripting language:

      1. Has lots of bindings to libraries and tools which are written in other languages, usually compiled ones.
      2. Is used for gluing third-party code and external programs and for high-level logic as opposed to grunt work and computations.
      3. The source file is the presumed redistribution form of the program, and is directly runnable.
      4. Features aimed at programmer convenience rather than preventing errors or improving performance, which includes dynamic typing.

      This makes P

    • Re: (Score:3, Informative)

      by ignavus (213578)

      Scripting languages are stored as text files, and are (mostly) compiled into some kind of intermediate or binary form *only at runtime*. Examples are Javascript and PHP.

      Byte-code languages are stored in a platform-neutral ("virtual machine") binary code, and then this is interpreted - or else compiled into real machine code - at runtime. Examples are Java and ActionScript (in Adobe Flash).

      Compiled languages are stored as real machine binary code, formatted according to the specific platform they were compil

  • Syntax argument. (Score:3, Insightful)

    by BitterOldGUy (1330491) on Friday August 29, 2008 @04:30PM (#24801753)
    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.

    • by belmolis (702863) <billposer AT alum DOT mit DOT edu> on Friday August 29, 2008 @04:37PM (#24801893) Homepage

      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: (Score:3, Insightful)

      by Just Some Guy (3352)

      Yeah, yeah, one language make it easier for the programmer to manipulate text or to develop some functionality for a particular task. But this jazz of "the right tool for the right job" is non-sense. We're talking about programming languages: not screwdrivers, drills and hammers. It's all going to be a processor's instruction set one way or another.

      Sure! So Python and COBOL are exactly equivalent and there's no real reason you'd pick one over the other.

      You know, there's more to a language than Turing completeness.

  • Major players? (Score:4, Informative)

    by Peter Cooper (660482) on Friday August 29, 2008 @04:35PM (#24801849) Homepage Journal

    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?

    • by belmolis (702863)

      I'm guessing they wanted to include Microsoft and since Microsoft isn't a significant player in the scripting language area, they picked Microsoft's best scripting project, even though it isn't particularly important within the Ruby community.

      • Re:Major players? (Score:5, Informative)

        by Esther Schindler (16185) <esther@bitranch.com> on Friday August 29, 2008 @05:01PM (#24802433) Homepage

        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.

    • by coryking (104614) * on Friday August 29, 2008 @07:13PM (#24804219) Homepage Journal

      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.

  • by bcrowell (177657) on Friday August 29, 2008 @04:41PM (#24801967) Homepage

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

    • I've had the same experience with CPAN: the code is often not very good, or the library doesn't really do what you expect it to do - a lot of contributions seem to be half-baked. In contrast, I have had a good experience with Tcl libraries. Perhaps one reason is that people put the half-baked stuff on the wiki (http://wiki.tcl.tk [wiki.tcl.tk]), where it is labeled as such, and don't present a full package until it is reasonably mature.

      • by Abcd1234 (188840)

        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.

  • by Animats (122034) on Friday August 29, 2008 @04:52PM (#24802219) Homepage

    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.

    • by belmolis (702863)

      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.

    • by Bogtha (906264) on Friday August 29, 2008 @05:30PM (#24802953)

      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 [python.org] 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 [python.org] seems like good coordination to me and easy_install psycopg2 and similar have never let me down.

    • by Abcd1234 (188840) on Friday August 29, 2008 @05:31PM (#24802961) Homepage

      There's a Perl 6 effort, with a major language redesign, expected to ship shortly after Duke Nukem Forever.

      Only someone who hasn't been paying attention would believe that. Perl 6, the language, is largely completely specified at this point. Meanwhile, Pugs has gone a long, long way to a working Perl 6 implementation, and the vast strides in Parrot mean Rakudo, the Perl6-on-Parrot implementation, has made immense progress in the last six months.

      Does that means Perl 6 will be out this year? No. There's still plenty of work to do. But the idea that Perl 6 has anything at all in common with DNF (which, unlike Perl 6, has suffered from constantly changing specs, engines, etc) is incredibly insulting to all those who are working to make Perl 6 a reality.

      • Re: (Score:3, Informative)

        by chromatic (9471)

        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.

  • What did they use to code the Matrix?
    • Shaper [netspace.net.au].

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

  • by tcopeland (32225) <tom@tho m a s l e e c o p e land.com> on Friday August 29, 2008 @04:56PM (#24802313) Homepage

    I hear a lot about Ruby performance - specifically, "Ruby/Rails can't scale". The odd thing is that this is in the context of a web app, where the overhead of the interpreter opcode execution is dwarfed by the cost of going over a socket to pull data across a LAN from a database. Scaling a web app isn't about the language; it's about architecture, judicious SQL optimizations, and caching.

    Oh, and if you're using rcov to measure your Rails app's code coverage, try this patch [blogs.com] to prevent rcov segfaults. It doesn't fix the root problem, but it's a start.

  • by kimanaw (795600) on Friday August 29, 2008 @05:01PM (#24802417)
    I was surprised that Groovy [codehaus.org] 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.
    • by Esther Schindler (16185) <esther@bitranch.com> on Friday August 29, 2008 @05:09PM (#24802549) Homepage

      It was a conscious omission... or perhaps semi-conscious. Lynn and I thought that if we were going to revisit the topic we should look at the same languages we did before.

      I do want to cover Groovy at CIO.com, honest. Just haven't had a good hook for it yet. I feel like there's an opportunity for "&number; programming languages your developers wish you'd let them use" aimed at CIOs and IT managers, with Groovy probably top on the list. But I don't know what else ought to be on the list, so I haven't done anything with this idea. Suggestions always welcome.—Esther

      • Re: (Score:3, Informative)

        by LynnG (1353897)
        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
  • Good timing (Score:2, Interesting)

    by adpe (805723)
    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
  • by kimanaw (795600) on Friday August 29, 2008 @05:34PM (#24803003)
  • by Anonymous Coward on Friday August 29, 2008 @06:26PM (#24803705)

    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*

  • by the_arrow (171557) on Friday August 29, 2008 @09:02PM (#24805239) Homepage

    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.

The only problem with being a man of leisure is that you can never stop and take a rest.

Working...