Forgot your password?
typodupeerror
This discussion has been archived. No new comments can be posted.

RubyGems' Module Count Soon To Surpass CPAN's

Comments Filter:
  • by ezzzD55J (697465) <slashdot5@scum.org> on Monday December 20, 2010 @07:38AM (#34614262) Homepage
    The dots in the graph there's actually a 6 months gap in the data, and the line is still drawn to suggest perfect linear growth; horrible visualisation.
    • by Anonymous Coward on Monday December 20, 2010 @09:10AM (#34614596)

      In general, quality and correctness have never been major concerns of the Ruby, and especially Rails, communities. Their goal is to produce large amounts of software quickly, even if it's shitty, doesn't do what it's supposed to, and even if it outright fucks up. It doesn't surprise me at all that they'd produce a blatantly incorrect graph like that.

      The Ruby and Rails communities consider things like monkey patching and duck typing to be acceptable in large-scale applications. Anyone with any experience developing significant software systems knows that those are among the stupidest things you can do, and they do adversely affect the quality of the software system.

      The mere concept of monkey patching should throw up red flags immediately. It's a horrible idea to change code at runtime, especially when that code is part of widely-used standard classes like String or even Object. Not only does it reduce the quality of your own code, but it can easily affect completely independent libraries your app may be using.

      Then there are the ActiveRecord shenanigans. It makes Ruby developers think they don't need even a basic understanding of relational databases, so they have no idea what it's actually doing under the hood. Then they wonder why their app's performance is absolutely horrible. Well, that'll happen when your ORM fucks up and pulls in 1.5 million records into memory just to do some filtering that could have easily been done in the database.

      I'd rather have CPAN's thousands of modules, most of which are extremely high quality and reliable, versus a larger number of shitty Ruby "gems".

      • by Bigos (857389) on Monday December 20, 2010 @10:51AM (#34615304)
        The fact that Ruby and Rails make bad programming practices possible doesn't prove anything. The same can be said about any language. I'd rather apply something that has been already said about Lisp. Ruby and Rails are programmer amplifiers, making performance of bad programmers worse, and good programmers even better. Monkey patching can be a very powerful approach, if used properly. It makes possible to write very readable code. It's not so much about changing your code but rather extending it. It can be a very useful technique if used properly.
        • by Unequivocal (155957) on Monday December 20, 2010 @03:52PM (#34619674)

          In theory you're right, but I have a significant amount experience with Ruby gems and and I have to agree with the OP's assertion that there's a ton of crappy quality software modules out there for Ruby. Granted it's not just b/c Ruby permits monkey patching and other "quirky" programming techniques. I personally love to have those techniques available to me (debugging things is *so* much easier sometimes with a monkey patch).

          Even some of the "core" libraries that ship with Ruby are total BS. Take REXML just for examples. It *appears* to be a robust XML parsing library and it ships with Ruby (or it did last time I looked). What a piece of junk - I had to rip it out after I had too many problems with it (chewing up memory, inconsistent implementation, not adhering to xml specs) and after talking it around, I'm not the only one. The net utilities are also pretty much BS. Gzip? I ended up shelling out to gzip b/c the tools just fail at random for no reason (and to top it off, the discussion forums talk about the failures/bugs but no one fixes them - I tried to get into the code to do it myself but as OP says, the monkey patch nonsense makes the code hard to get started on - faster just to shell out to a tool I know works).

          I ended having to rewrite the XML pieces I needed by hand and it works fine -- and that proves your point. There's nothing inherent about Ruby that prevents decent code. It's just that there's a lot (a lot!) of half-baked junk out there masquerading as quality software libs. /rantoff

        • by afabbro (33948) on Monday December 20, 2010 @04:23PM (#34620202) Homepage

          The fact that Ruby and Rails make bad programming practices possible doesn't prove anything.

          What percentage of Ruby usage is Ruby on Rails? I honestly don't know...just curious.

      • by kill-1 (36256) on Monday December 20, 2010 @12:18PM (#34616188)

        Yes, I wonder how many gems even have a test suite. CPAN modules are pretty good in that regard.

        • That's tricky.

          There is a large and vocal Ruby community of behavior-driven design. Tools like RSpec in particular show just how well this works in Ruby, compared to other languages, and all the major projects (including Rails) use and encourage tests -- basically, if you want a change in Rails, you're going to need to write a test which describes the change, which fails on the current trunk and passes with your patch.

          But there's also a large and nearly silent community of people who just throw up a gem (because of how absurdly easy it is) without much in the way of docs or tests. And that's cool, too -- even if your project sucks and is in ridiculously early alpha, even if you're still learning the language (or learning to program), it means it's easy to get at your code.

          I haven't used CPAN enough to know how it compares, but there are very good gems, and very bad gems, and very unorthodox gems. I think you have to allow the bad ones to also allow the unorthodox ones, and I think it's a strong community overall, but CPAN was pretty damned good, so we might have a ways to go.

          What I think we need more of is a way to rank and rate gems, so you don't have to be on the mailing list for months just so you know offhand that Nokogiri has replaced Hpricot (and certainly rexml) as the best html/xml parsing suite.

      • In general, quality and correctness have never been major concerns of the Ruby, and especially Rails, communities.

        Is that why Rails won't even look at your patch unless you have a unit test proving it does what you say it does?

        The Ruby and Rails communities consider things like monkey patching and duck typing to be acceptable in large-scale applications.

        Duck typing yes, monkey patching no. It's awesome that monkey patching exists, but the Merb guys introduced the idea that if you couldn't write a Merb plugin you wanted to with the plugin API (that is, if you had to monkey-patch), it was a bug in Merb. Merb has since been merged into Rails, so the same should be true of Rails.

        It's a horrible idea to change code at runtime, especially when that code is part of widely-used standard classes like String or even Object...

        Define "at runtime." These modifications are made at the beginning of your program, and they're made in every Rails app. You know that if you're going to use Rails, you're going to have these things. (This being Rails, I bet there's a way to disable it, too.)

        They also don't interfere with any other usage of those core classes, to the point where one or two have actually been adopted into the language. It is a good thing that Ruby allows you to fix problems with the core language.

        And compare to pretty much any Java servlet environment. Oracle's WebLogic, for instance, entirely stripped out and replaced the (working) SSL stuff and replaced it with their own broken shit that couldn't handle wildcard certificates. The only mechanism they provide for undoing that is to write your own HostnameVerifier and sort of monkey-patch it back to working the way it did.

        So, talking about just the core hacks:

        Not only does it reduce the quality of your own code,

        How so?

        it can easily affect completely independent libraries your app may be using.

        Name one which is affected by this.

        Then there are the ActiveRecord shenanigans.

        Not going to try to defend this too much, as I use DataMapper, but...

        It makes Ruby developers think they don't need even a basic understanding of relational databases, so they have no idea what it's actually doing under the hood.

        That's too bad, but that's not the point.

        The fact that something enables shitty code is irrelevant. The question is, what can a good developer do with it? Does it enable awesome code, or does it actively discourage it, the way some platforms do?

        Well, that'll happen when your ORM fucks up and pulls in 1.5 million records into memory just to do some filtering that could have easily been done in the database.

        You can as easily do this with any decent ORM. The point is that you shouldn't ever do that, because you should have an understading of how the underlying technology works. As Joel Spolsky says [joelonsoftware.com], "the abstractions save us time working, but they don't save us time learning."

        See, I know SQL, and ActiveRecord and DataMapper make me more productive than writing raw SQL. If I didn't know SQL, yeah, I'd probably write some ActiveRecord that'd really suck.

        I'd rather have CPAN's thousands of modules, most of which are extremely high quality and reliable, versus a larger number of shitty Ruby "gems".

        I'd rather have thousands of high quality modules in a language I like, even if I have to sort through which ones are shitty or not (I actually like being able to make that call myself), rather than a language which looks shitty on its best days (and can be made to look like line noise).

        Basically, Sinatra [sinatrarb.com], Nokogiri [nokogiri.org], an

      • by julesh (229690) on Monday December 20, 2010 @01:48PM (#34617694)

        Anyone with any experience developing significant software systems knows that [duck typing is] among the stupidest things you can do, and [it does] adversely affect the quality of the software system.

        Meh. I've seen programmers much more experienced than me and (I'm going to guess) you argue it both ways. this one's [msdn.com] an interesting discussion, but there are plenty more out there.

        I'd rather have CPAN's thousands of modules, most of which are extremely high quality and reliable, versus a larger number of shitty Ruby "gems".

        Well, I've never looked through the ruby "gems" collection, but my experience with CPAN has been that Sturgeon's Law most definitely applies. Maybe it's improved since I last used it (I stopped being a Perl programmer the best part of 10 years ago), but there's definitely a lot of crap in there.

        In the end, I don't think either Perl or Ruby are the way forward, and that's not because of typing issues but because both languages seem aimed at people who think that cute syntax and being able to do everything in 50 different ways is beneficial. It isn't. Conditionals written after the statements they effect? That's a much worse idea than duck typing, because it can completely change how you parse the code you're reading *after* you read it. Worst case: the condition is scrolled off the right hand edge of the page and you don't notice it (yes, I've seen this happen).

        I do agree about "monkey patching" though (hadn't come across the term before, but I hate it when it's done in javascript, and I don't imagine it's much better in ruby).

      • by goombah99 (560566) on Monday December 20, 2010 @03:31PM (#34619310)

        Back in the days of print media, graduate students used to remark that the ever expanding bound volumes of the Journal of chemical physics were enlarging so fast that in a few years they would be spreading across library shelves faster than the speed of light. But this did not violate einstein's principle because they contained no information.

        If you compare older perl libs with more modern python and ruby libs you fins a lot of object oriented bloat and dependencies in the latter. It's the modern way of programming for the general case. perl tended to have more self contained solution sets, to over generalize a bit. I think this means that there's a lot of layered foam and filler in those general libraries.

        After detouring in to python I've found myself going back to perl a lot. Why? well when python was young I admired it's clean lines and one way to do one thing. It made everyone elses code easy to read. the white space idea forced every one to indent the same, again making everyone elses code as easy to read as mine. loved it. But then it bloated and things depricated. Meanwhile perl just went along without changing much at all.

        if you pick up an O-reily quick reference for perl it is half as thick as the one for python. Moreover it actually contains all of perl where as useful stuff in python (like regex and ties and math) is farmed out to includes. You can memorize perl and the parts you memorize are not deprecated. Whereas the includes in python are being depricated quickly.

        No doubt this is the evolution of many languages. when you come in early it's clean but perhaps is missing stuff or has idiosyncrasies that need removing to extend it. Then it bloats and something new like Groovy is more sexy looking.

        Perl mean while keeps simple things simple be hard things possible in the main trunk of the language.

        I'd still rather write a large complex program in python. But perl has stayed suprisingly relevant, not to mention being a much better system admin language. In my dream, all shell languages would be replaced by perl.

  • Real use (Score:5, Interesting)

    by isorox (205688) on Monday December 20, 2010 @07:38AM (#34614264) Homepage Journal

    Obviously there's some real projects out there using Ruby, is it mainly internal stuff? There's some big contenders for things like PHP (wikipedia probably being the biggest). Does Ruby factor in to any public-facing websites of note? Or is it mainly used in the corporate space in the area where you often find tomcat?

    • by eldavojohn (898314) * <eldavojohnNO@SPAMgmail.com> on Monday December 20, 2010 @08:07AM (#34614356) Journal

      Obviously there's some real projects out there using Ruby, is it mainly internal stuff? There's some big contenders for things like PHP (wikipedia probably being the biggest). Does Ruby factor in to any public-facing websites of note? Or is it mainly used in the corporate space in the area where you often find tomcat?

      What we use it for at my company is quick prototyping. Especially with Rails. But it's important to note that Ruby is the language and Rails is the framework. These modules could just be a niche field like academia finding it easy to write and share these modules through this site. I'd say that's unlikely given the number and you're most certainly seeing businesses promote some of this. I will say that we actively use hundreds of gems and I'm not sure what the average module:gem ratio would be in these projects -- as far as I can tell, I think it's 1:1 on a lot of the major ones we depend on.

      Here's a list of some websites you might know using Ruby [storecrowd.com]. The most notable is Twitter who I think is starting to componentize its pieces and move the high load intensive pieces to Scala [theregister.co.uk]. That's not to say they're completely off of Ruby but I think it's a sign that Rails needs a little more maturity before it is going to be seen on a website the size of Facebook. You'll see small to medium efforts excel at Ruby on Rails but the very very giant beasts are still too big for it at the moment. That means that you have a high number of websites using it but the representation is skewed against it since your big sites that everyone use aren't going to trust its maturity yet.

      great language. It's simple, elegant, clean and it is versatile. Rails muddies that up a bit but Rails is great for prototyping web applications. In my opinion, the increase in the number of modules shows how versatile the language is and how wildly people want to extend it. It really does have a lot of metaprogramming facets that I've been impressed with and I think that we're going to see a rise of languages like Ruby and Clojure that allow you to do interesting things like write a domain specific language (DST). But will they ever usurp the big old giant languages that command a presence? I guess only time will tell. For web programming, I prefer Ruby to Java when prototyping or writing anything for less than thousands of users. That's where it stands right now but Ruby usage has grown by leaps and bounds and I don't think this module tracking story is a fluke. I think we'll see a steady rise in Ruby modules as people explore its potential. The quality, the performance, the diversity, the revenue can all be questioned but the number of modules is most likely there.

      • by Anonymous Coward on Monday December 20, 2010 @08:40AM (#34614478)

        Huge sites like Twitter or Facebook have special needs that are unlikely to be there for 9 out of 10 other sites. Sure, it's an honor to have "your" language picked at some point for such a large scale / high availability service, but they will eventually switch to something else as the technology evolves, or the needs of the site change, and so on.

        Bottom line: if Twitter or Facebook used Ruby at some point in time for certain things doesn't mean it will be good for you and your site. It means it has certain qualities and you should research whether they're useful to you.

    • Re:Real use (Score:3, Informative)

      by graznar (537071) on Monday December 20, 2010 @09:11AM (#34614598) Homepage
      Here's a quick list just off the top of my head: * YellowPages.com * All of the 37signals apps (Basecamp, Campfire, etc.) * Hulu * Scribd * LivingSocial * Penny Arcade * GitHub * Twitter (backend powered by a ton of stuff but their frontend is mostly Rails) * Chow.com * Oracle.Mix * Shopify * Justin.tv * Crunchbase There are a ton more public facing and even more (as you mention) sort of "behind the firewall" type stuff. Ruby (especially Rails) has stepped up as a pretty major contender in the web development arena. :)
    • by burris (122191) on Monday December 20, 2010 @09:13AM (#34614606)

      Ruby people make some cool tools that you can use even if your code isn't written in Ruby. Check out Chef [opscode.com] and Vagrant [vagrantup.com]. Both are configured with Ruby, which is amenable to making DSLs.

    • by ToasterMonkey (467067) on Monday December 20, 2010 @11:37AM (#34615692) Homepage

      Obviously there's some real projects out there using Ruby, is it mainly internal stuff? There's some big contenders for things like PHP (wikipedia probably being the biggest). Does Ruby factor in to any public-facing websites of note? Or is it mainly used in the corporate space in the area where you often find tomcat?

      yes

    • by Unequivocal (155957) on Monday December 20, 2010 @03:56PM (#34619730)

      Doesn't twitter use Ruby to some significant extent? I think they used to run the whole thing on Ruby but as they got big, they had to back that off as it was wasting too many cpu cycles parsing. I've read that their bottom end runs a lot of C now but the interface still has Ruby bits I think? Anyone has current knowledge?

  • by cerberusss (660701) on Monday December 20, 2010 @07:42AM (#34614280) Homepage Journal

    Big numbers, but you have to be very careful what you pick. Do you want to go with community-based support? Pick the most-used module. Want to maintain it yourself? Pick the one with the best code quality. Do you need specific performance? Test them all. Et cetera.

    Besides, it's pretty obvious that Perl usage is slowly declining. The idiosyncrasies of Perl 5 get very annoying. And Perl 6 has been 10 years in development and is still not very popular in production and everybody is switching to more modern languages like Python and Ruby. At my job (a scientific institute), we're ditching Perl 5 for Python.

    • by Lazy Jones (8403) on Monday December 20, 2010 @08:06AM (#34614348) Homepage Journal

      The idiosyncrasies of Perl 5 get very annoying.

      Like what? I can't really think of anything annoying enough to bear mentioning, except perhaps that typos are hard to find with warnings off (and sometimes with warnings on as well).

      everybody is switching to more modern languages like Python and Ruby. At my job (a scientific institute), we're ditching Perl 5 for Python.

      Ruby is certainly modern, but Python? It's a poor choice IMO when it comes to fixing Perl's biggest problem, threading support/concurrency due to its GIL, some Ruby implementations fare better. We'll stick to Perl for now, our parallelizable problems are generally tackled using Gearman and apart from a lack of decent programmers, we haven't found any real issues lately.

      • by Waffle Iron (339739) on Monday December 20, 2010 @10:09AM (#34614958)

        Like what?

        Off the top of my head: How about no visibly defined function parameters; object oriented features are stuck on with duct tape; you have to have a deep understanding of the language to understand what's really going on when someone assigns between variables that have different sidgils; huge numbers of built-in magic 2-character variable names that you can't remember without a cheat sheet.

        • by oscartheduck (866357) on Monday December 20, 2010 @11:14AM (#34615482)

          Off the top of my head: How about no visibly defined function parameters

          I might be totally misreading you here, but are you saying that you can't put a function prototype into a function definition?

        • by Junta (36770) on Monday December 20, 2010 @11:20AM (#34615536)

          How about no visibly defined function parameters

          Well, you can, but it's optional (like a lot of perl). I actually like one aspect of an argument list that is more obviously nothing more than an open ended stack, it gets developers to think more open ended about arguments they can receive. In C, it's a relative pain, you must know the number of arguments you need. If you treat it as simple arguments being passed in, it's extremely static. If you are going to accept arbitrary number of parameters, you need the caller to tell you how deep the stack is rather than being able to tell implicitly.

          object oriented features are stuck on with duct tape

          When you get deep into it, this is probably still a fair criticism. However, an interesting side effect is that the well equipped programmer becomes more cognizant of the structure of things and is not confined by arbitrary simplifications in the name of ease-of-use. Of course, a good programmer will exercise self-restraint and make things comprehensible to others.

          you have to have a deep understanding of the language to understand what's really going on when someone assigns between variables that have different sidgils

          Most languages have something like that, a feature that is not required that isn't obvious at first blush. In my case, I avoid those operations in favor of more readable code. For example, 'my $arrlength = @array;' is something I avoid in favor of the more explicit and obvious 'my $arrlength = scalar(@array);'. They are exactly the same, but the sidgils may get overlooked in the first example. I suppose you'll say 'scalar' does not eliminate the need to have a 'deep understanding', I would say that it isn't a particularly deep bit of knowledge to know that arrays assigned to a simple variable is doing the length. deep knowledge is trying to write XS code or use gdb to debug perl at the level of C.

          huge numbers of built-in magic 2-character variable names that you can't remember without a cheat sheet.

          True enough there, but many are unused and again, from a style perspective, I avoid many of them (like $_ in particular).

      • by Junta (36770) on Monday December 20, 2010 @11:31AM (#34615626)

        Perl's biggest problem in new developer 'recruitment' is a world that is obsessed with concepts of 'new is better'. This is at least the case in academia and discussion places like slashdot. In industry, I find many hands-off architects that never touch code and have next to no ongoing commitment to any particular project push hard for starting or converting to Python or Ruby (the latter is only ever mentioned with 'on Rails' at the end by these guys, even if having nothing to do with the web for some particularly clueless people). In practice, the people dealing with where the rubber meets the road most often go with perl of the scripting languages. The reason is simple, it is sufficient, relatively unchanging, and well-known. I'd rather have an 'odd' language that doesn't change it's mind about things than a language striving to be 'clean' and deprecating things left and right when people decide there is a 'cleaner' way of doing it (mainly some experiences with python projects coping with 2.x series changes over time, though admittedly going from using a project pre-adoption into python core to having that project pulled in and changed).

        When it comes down to it, currently used interpreted languages are alive for a reason and generally you can choose any one you like and get to the goal without too much difficulty. Python, Perl, Ruby, even Powershell (as of 2k8r2 and 7) represent pretty capable languages to write in. Personal preference and available experience outweigh the technical differences in my opinion.

        • by bjourne (1034822) on Monday December 20, 2010 @12:50PM (#34616764) Homepage Journal

          When it comes down to it, currently used interpreted languages are alive for a reason and generally you can choose any one you like and get to the goal without too much difficulty. Python, Perl, Ruby, even Powershell (as of 2k8r2 and 7) represent pretty capable languages to write in. Personal preference and available experience outweigh the technical differences in my opinion.

          The reason you say this is because you have little to no experience with Ruby or Python. I can't comment on Powershell since I don't know it enough. Though I can say without doubt that Python and Ruby is a superior choice to Perl for new systems.

          • by Junta (36770) on Monday December 20, 2010 @05:52PM (#34621430)

            I say that because people make too big a deal of the differences between interpreted languages. I have done python extensively. Admittedly, I've only spot checked ruby code. Preferences are a matter of subjective taste and not so much slam-dunk, absolutely better. I will admit I have a hard time imagining anyone preferring perl's XS strategy for writing perl bindings to C/C++ API to python's, but I'm hard pressed to think of another area where perl cannot be used to the same effect as python without undue difficulty.

    • by Chapter80 (926879) on Monday December 20, 2010 @08:37AM (#34614468)

      Besides, it's pretty obvious that Perl usage is slowly declining.

      I can't comment on the trend (declining or ascending?), but it sure looks like perl is still pretty popular, on this comment from last month [slashdot.org].

      It says:

      Dice has a lot more programming listings than Monster.

      Java - 14824 .Net OR C# - 10496
      C++ - 5789
      Perl - 4664
      PHP - 2499
      Python - 2196
      Objective C - 1267
      Ruby - 1169
      Cobol - 638

      (bolding emphasis mine)

      • by happy_place (632005) on Monday December 20, 2010 @09:46AM (#34614802) Homepage

        I think Perl is a fantastic language--in fact it's my favorite language of all time. Heck, I just released a new tool at my work last week using Perl and CGI to help organize about 4 years worth of file changes from an active CVS archive into relevant categories.

        Perl's not a language for the faint-hearted, however. It is not a language you sit down and instantly you have a webpage going--which is what most people want to do these days when it comes to casual programming. For that, PHP and Ruby seem to be a lot more accessible.

        I've been using Perl for over ten years now, and I find that I'm still learning something new about how to use the language in fascinating ways--pretty much every day. Nothing compares to Perl's community. You can talk with experts daily if you like, on sites like http://www.perlmonks.org/ [perlmonks.org] and the documentation is all accessible at http://perldoc.perl.org/ [perl.org] or with every install of perl by just typing perldoc... I love how easy it is to move data about. It really was the first language to fully incorporate hashing as a basic operator and though variable sigils confuse a lot of people used to simpler programming languages, such notation allows for some amazingly flexible operations without the need to create lengthy method calls for every basic operation on your data structures. In Perl every symbol has specific/distinct meaning and interoperates with all others, and those combinations make for some very powerful programs with few lines of code--like how you can load full hashes by acessing them with the array operator as hash slices... and who can compare to Perl's enhanced regular expressions, especially the latest from v. 5.12...

        Anyhow there are languages for the pedantic, there are languages for your project managers and your CS grads, and for your code-generators--or for outsourcing to India, and then there's languages that really get your inner geek going... and Perl definitely reigns supreme for my inner geek. :)

        In fact, Some people call it magic.

      • by Chapter80 (926879) on Monday December 20, 2010 @01:19PM (#34617196)

        Wow, I should post in my sleep more often!

        I copied someone else's post, linked to it with a bad link, and got a Score 5, Interesting.

        Sorry folks, here's the real link [slashdot.org]

        It says
        Dice has a lot more programming listings than Monster.

        Java - 14824 .Net OR C# - 10496
        C++ - 5789
        Perl - 4664
        PHP - 2499
        Python - 2196
        Objective C - 1267
        Ruby - 1169
        Cobol - 638

        This is the number of jobs available using various languages. Since this article compares Ruby and Perl's respective contributed libraries, I think it's interesting that there are 4 times as many Perl jobs as Ruby jobs.

        Implying that Ruby is as popular as Perl based on the library stats might be as valid as saying that Ruby is not even twice as popular as Cobol based on the job stats.... hmmm...

        • by Unequivocal (155957) on Monday December 20, 2010 @06:11PM (#34621716)

          Yes but which one of those jobs would a programmer want? Perl is highly in demand - that's great. But if I'm an above average programmer do I want to work in the bowels of a bank, figuring out 10 year old perl parsing of bank transactions or work on a shiny new Ruby web app, where they have super smart co-workers, a ping pong table, free soft drinks and happy hour twice a month? Quantity of job listings shouldn't be the only measure to drive language to learn and which jobs to apply for..

          I'm not suggesting that's what you're saying, I'm simply trying to add on an additional layer to the analysis.

    • There is a tremendous push for Python in the scientific community (except for the people still using Fortran)

    • by gtirloni (1531285) on Monday December 20, 2010 @09:07AM (#34614582)
      I haven't coded a line of Perl in a while. It's mostly fixing bugs in legacy Perl code and migrating everything to Python. Ruby seems to have some traction now but I find it's as hard to read as Perl. They have to much implicit information. It's convention over explicit... I don't like that.
  • by Anonymous Coward on Monday December 20, 2010 @07:44AM (#34614286)

    How many of those modules are solely focused on converting a string to uppercase?

    • by TheRaven64 (641858) on Monday December 20, 2010 @10:52AM (#34615312) Journal

      And how many of them are duplicating functionality of others, but with a slightly different interface? And how many are doing something that is so domain-specific that they are unlikely to be of use to anyone other than the author? And how many are so buggy that they are no use to anyone including the author?

      The number of modules is an irrelevant statistic without some measure of utility. I could write a program that would generate Perl or Ruby modules (UNIX systems typically actually ship with one for Perl, in /dev/random). They'd all be useless, but I'd have more and be growing faster than either of the sites in question...

  • by pedantic bore (740196) on Monday December 20, 2010 @07:48AM (#34614296)

    It doesn't matter how many modules there are. It matters how many solid, well-documented modules there are that will continue to get updates and support.

    I have no opinion over how much goodness there is in CPAN versus RubyGems; maybe RubyGems is really pulling ahead. But out of nearly nineteen thousand modules, how many really matter? (and how many are just another XML library that's just slightly different and incompatible with the bajillion other XML libraries already out there?)

    • by freedumb2000 (966222) on Monday December 20, 2010 @08:57AM (#34614546)
      I am a huge ruby fan, but I must agree. Much more relevant would be a graph with module count and factoring in development activity. In reality, a huge number of the gems are orphans, or come never out of alpha.
  • by petes_PoV (912422) on Monday December 20, 2010 @08:38AM (#34614470)
    Personally I don't care how many modules any repository has, just so long as the ones I want to use work properly. That will always be my primary measure of success, followed closely by how well they are documented and then by how easy they are to find and use.
    • by ascari (1400977) on Monday December 20, 2010 @09:15AM (#34614612)

      Yes! I was just going to say the same thing. Please mod this man up, I don't have points!

      On the other hand, perl is a "mature" language it's likely that many modules already exist and are in widespread use, thus pace of new development is slowing down. Ruby is on the up ramp of its life cycle, and consequently a lot of stuff has to be developed for it. Revisit in five years and I'd guess both repositories will have about the same number of modules.

  • by damn_registrars (1103043) <damn.registrars@gmail.com> on Monday December 20, 2010 @08:38AM (#34614472) Homepage Journal
    Someone needs to write a Perl module to go through the Ruby gems to figure out which gems are redundant with other gems, or abandoned. Once those are tossed out of the count, and the Perl module count is incremented by one for this additional module, Perl should be able to hold of Ruby until at least New Years!
  • DLL hell (Score:5, Insightful)

    by Jay Maynard (54798) on Monday December 20, 2010 @08:43AM (#34614492) Homepage

    I sure hope RubyGems isn't the utter DLL hell that CPAN is. The only time I tried shipping a product based on CPAN stuff, I wound up shipping the entire bundle as one, because there's just no way to download it from CPAN and depend on having the exact versions of the modules you developed with available - and when they're not, you're stuck in a messy cycle of upgrade dependencies and API incompatibilities that are almost impossible to resolve.

    • Re:DLL hell (Score:2, Offtopic)

      by hachete (473378) on Monday December 20, 2010 @09:07AM (#34614584) Homepage Journal

      Give this man some mod points. CPAN hell. And CPAN bloat - how many different modules for building modules does one need? 3? 4? 5?

      And fragility - I made the mistake of upgrading a package once, only having to re-wind it because of the knock-on effect through the rest of the module hierarchy.

    • by bill_mcgonigle (4333) * on Monday December 20, 2010 @10:07AM (#34614932) Homepage Journal

      The only time I tried shipping a product based on CPAN stuff, I wound up shipping the entire bundle as one, because there's just no way to download it from CPAN and depend on having the exact versions of the modules you developed with available

      Good choice, that's what you're supposed to do if you're shipping a product. Perl includes tools to help you do this. Fortunately, your app was probably stored on $1 worth of storage.

      You could also specify a no-breakage OS (e.g. RHEL, debian stable) and write your app to what they're shipping.

      • by TheLink (130905) on Monday December 20, 2010 @11:34AM (#34615662) Journal

        Good choice, that's what you're supposed to do if you're shipping a product. Perl includes tools to help you do this.

        Say your perl program needs https/SSL and needs to run on all the popular linux distros. How many packages do you have to build just to support the relatively small numbers of "Desktop Linux" users?

        Correct me if I'm wrong but it seems for you'd have to build different packages for Ubuntu, Suse, Redhat, Debian, etc? Would 32/64 bit and glibc versions also make a diff?

        Fortunately, your app was probably stored on $1 worth of storage.

        In most cases the storage doesn't matter much. It's the amount of work involved for the $$$.

        • by bill_mcgonigle (4333) * on Monday December 20, 2010 @01:24PM (#34617262) Homepage Journal

          Correct me if I'm wrong but it seems for you'd have to build different packages for Ubuntu, Suse, Redhat, Debian, etc? Would 32/64 bit and glibc versions also make a diff?

          I think it would depend on the major version of OpenSSL, but they should all have OpenSSL. Same as any other app, a 32-bit version should be able to run on 64-bit OS with compatibility libs, but not without. Native needs native.

          Perl modules are often available in "pure perl" and "XS" versions. The pure perl versions don't have these problems, and can be slower. The XS versions are just object code (c-compatible) and have the same problems any other bit of c code would. Sometimes the speed boost is worth it, sometimes it's not. Sometimes one or the other is available, sometimes both. Sometimes people do a port from one way to the other when speed or portability is important or not.

          In general, it's easier than building for all the different flavors of Windows that are out there (2000,XP,Vista,7). Apple makes this somewhat easier by cutting off their old users at the knees pretty rapidly, but even there major library version differences can exist on the two supported releases.

  • by Anonymous Coward on Monday December 20, 2010 @08:49AM (#34614518)

    pl-2-rb.pl converted 17,894 of those.

  • by mr_mischief (456295) on Monday December 20, 2010 @09:35AM (#34614730) Journal

    search.cpan.org [cpan.org] states that there are 88,679 modules in 21,580 module distributions. It further says there have been 63,291 uploads by 8659 uploaders (authors).
    Perl also has over 600 modules in the core distribution (as of 5.12.2 anyway).

    On CPAN, a "module" is a module, and that's what it sounds like. A module is a program library that can be used by an application programmer. A module distribution is several related modules in a package. Some packages contain dozens of modules. Some may also contain example applications or helper applications along with the modules. PyPi also has packages which can be collections of modules. I don't mess with Python enough to tell you if that's common.

    So, RubyGems has over 18,00 "gems", but what does that mean?

    On RubyGems, it seems a "gem" can be anything. There are libraries there, sure. There are also applications. One, for example, is "vmail", which is a hack to let you read your GMail account in vim (using lynx for HTML mail viewing). Another is "rake", which is a software build program. You do have big frameworks pushed out as gems like "rack". There are smaller library modules that look useful, too. Then there's some stuff with no docs, no home page, and no apparent use. I found one "gem" that claims to redefined '==' to be more useful than in the standard library, but was all of 4 lines with no documentation.

    RubyGems seems to have no real organization other than new, recently updated, popular, and alphabetical. There is a search.

    CPAN and PyPi both have hierarchies of topics through which one can drill down. They have search, too. PyPi has probably the best combination of search and drill-down features of the three.

    CPAN has some things it's pretty clear RubyGems doesn't. It has an automated build and test system for modules. It has a ticketing system for the modules right there in the public repository. It has a rating system for the packages. It has 228 mirrors worldwide for downloading the packages, too.

  • by bill_mcgonigle (4333) * on Monday December 20, 2010 @10:12AM (#34614982) Homepage Journal

    Folks with a few spare cycles/resources who are growing tired of these 'module' measuring contests might want to throw a bone to Parrot VM [parrot.org]. Write a module in ruby, use it from perl6, python, lua, tcl, whatever, or pick any combination above.

    I won't wave the red flag explicitly, but suffice it to say I look forward to good ruby performance on parrot.

    • by Eivind Eklund (5161) on Monday December 20, 2010 @01:14PM (#34617120) Journal

      I have less hope for that than you. Using libraries (modules/frameworks/whatever) written for another language isn't usually as nice as using something that's native. There's different conventions, and there's usually features in each language that makes for an improved experience - for that language.

      For instance, in Ruby, I'd expect an API to actively use blocks (continuations) for resource tracking, and a DSL based on symbols and blocks would be common. Doing this in Python or Perl would be weird.

      In Python, I'd expect docstrings, and I'd expect exceptions, and the use of the standard module system, with one module per file, and the need to use import to get at the right constants etc.

      In Perl, I'd expect perldoc. I'd not expect exceptions, as that's not really well supported (at least in perl 5). And I'd expect there to be distinctions between references and 'real values'.

      Overall, I think that anything that's written in one language and automatically accessed from another language will interface clumsily. And if you have to write an abstraction layer to make it work, you often might as well have a native module without the quirks.

      Eivind.

    • by rubycodez (864176) on Monday December 20, 2010 @03:29PM (#34619258)

      The guts of a thousand whales (Perl 6) are too heavy a baggage for Parrot to be anything other than a fringe project. Face it, Larry killed Perl.

  • by Ant P. (974313) on Monday December 20, 2010 @01:20PM (#34617200) Homepage

    How many tests do each have, and how many of those do they fail?

Reality must take precedence over public relations, for Mother Nature cannot be fooled. -- R.P. Feynman

Working...