RubyGems' Module Count Soon To Surpass CPAN's

mfarver writes "According to the data gathered by modulecounts.com, the total number of modules checked into RubyGems (18,894, and growing at about 27/day) will probably exceed CPAN (18,928, and growing about 8/day) this week."

Comments

Huh

[ezzzD55J]

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.

Real use

[isorox]

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?

Re:Real use

[Anonymous Coward]

Ruby has zero real world penetration, it's a proven non-solution championed by the hipster crowd. Twitter was the posterchild until they replaced their RAILS backend with scala running on the JVM.

Re:Real use

[graznar]

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

Re:Real use

[burris]

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

Re:Real use

[ToasterMonkey]

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

Re:Real use

[Unequivocal]

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?

How many of those are maintained

[cerberusss]

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.

Re:How many of those are maintained

[Lazy Jones]

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.

Re:How many of those are maintained

[Chapter80]

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.

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)

Re:How many of those are maintained

[buchner.johannes]

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

Re:How many of those are maintained

[gtirloni]

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.

Re:How many of those are maintained

[Anonymous Coward]

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

And some of them use f2py.

Re:How many of those are maintained

[happy_place]

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/ and the documentation is all accessible at http://perldoc.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.

Re:How many of those are maintained

[Waffle Iron]

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.

Re:How many of those are maintained

[oscartheduck]

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?

Re:How many of those are maintained

[Junta]

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

Re:How many of those are maintained

[Junta]

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.

Re:How many of those are maintained

[bjourne]

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.

Re:How many of those are maintained

[Anonymous Coward]

You have been stuck somewhere before Perl 4. Try Perl 5.12.2 with Moose for OO-programming.

Re:How many of those are maintained

[Chapter80]

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

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

Re:How many of those are maintained

[Waffle Iron]

You have been stuck somewhere before Perl 4. Try Perl 5.12.2 with Moose for OO-programming.

Optional OO add-ons == FAIL. If different projects use different incompatible class systems from random 3rd party libraries they downloaded off the web, they may as well not even be written in the same language. They won't interoperate.

Re:How many of those are maintained

[chromatic]

How about no visibly defined function parameters...

That's a fair point until you use a module such as signatures or Method::Signatures.

object oriented features are stuck on with duct tape

Perl 5's default object system is basically Python's object system. Everything Python programmers complain about (explicit self) and everything Python programmers haven't figured out yet (the conflation of namespace and class with no distinguishing between function and method makes for fragile classes) is a misfeature shared between the two languages. Python offers little additional value there, and it suffers greatly when compared to Moose.

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 [sigils]

You only have to be able to understand subject/verb agreement in a spoken language (and you don't even have to know the term "subject/verb agreement"). That's one of the first things the book Modern Perl explains. (You can download it for free if you like.)

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

I've written a lot of Perl 5 over many years, and I can think of two or three I ever use. I could get that down to one.

Two substantial criticisms are "reference syntax is ugly", which is true and "most tutorials explain the language poorly", which is why I wrote what I believe to be a better book.

Re:How many of those are maintained

[chromatic]

If different projects use different incompatible class systems from random 3rd party libraries ...

Moose is fully compatible with default Perl 5 OO.

Re:How many of those are maintained

[Junta]

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.

Re:How many of those are maintained

[Unequivocal]

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.

Re:How many of those are maintained

[Chapter80]

Yup. Agreed.

But you paint the picture as if the only Perl jobs are 10-year old jobs of maintenance programming. I bet there are some cool ones out there, working on new development.

There are probably Rails-like frameworks for Perl (as much as Django is for Python, anyway). And working on cool new frameworks with a cool language sounds fun. That just might be Perl.

I like jobs that provide the flexibility to use the "right tool for the job", along with a healthy amount of learning new tools.

Re:How many of those are maintained

[Anonymous Coward]

You really should try ruby. I find it to be a better perl for everyday scripting.

Ruby has tools such as rvm which lets you manage multiple versions, with multiple groups of modules (ruby gems) - so you can isolate your environment easily.

Ruby also has a lot of the OO built in that you need Moose for in perl. It's also more consistent. Most of the language features can fit in the average person's head at all times, allowing you to focus on writing cleaner code.

Ruby has hashes, but also hashes with default values and blocks. Blocks make a lot of code less error prone, because a file open block will automatically cleanup and close the file when your code has finished.

Re:How many of those are maintained

[chromatic]

Ruby has tools such as rvm which lets you manage multiple versions...

So does Perl, with perlbrew.

Ruby also has a lot of the OO built in that you need Moose for in perl.

I use plenty of Moose features that Ruby doesn't have (and I find Perl's module and importing mechanism far more powerful than Ruby).

Most of the language features can fit in the average person's head at all times, allowing you to focus on writing cleaner code.

I don't believe that. Count the number of methods on core classes sometime.

Blocks make a lot of code less error prone, because a file open block will automatically cleanup and close the file when your code has finished.

Blocks are nice, but properly scoped lexical variables in Perl have this property as well. As a bonus, Perl gets lexical scoping right and readable, unlike both Python and Ruby.

Re:How many of those are maintained

[DocHoncho]

You can... but as they say in the docs it doesn't do what you think it would. It's mostly there for turning regular functions into "keywords" so

sub foobar($) ...

can be used like foobar "baz" instead of foobar("baz")

Oh, and it doesn't enforce the prototype either. It really can't since there are no types to speak of.
It's all very perlish.

Re:How many of those are maintained

[Yer Mom]

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

This is where use English; is your friend. Doesn't help if the previous guy wrote his code without it, of course.

Re:How many of those are maintained

[Anonymous Coward]

> How about no visibly defined function parameters

use MooseX::Method::Signatures;

> object oriented features are stuck on with duct tape

Moose is anything but 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

No, you only have to have some common sense and a basic understanding. Or are you the kind of loony that tries to assign a function reference to a hash and expects something sane to happen?

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

use English;

How many of those modules?

[Anonymous Coward]

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

Re:How many of those modules?

[TheRaven64]

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

Re:How many of those modules?

[fotoguzzi]

Quick! To the Patent Office!

Irrelevant statistic...

[pedantic bore]

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

Re:Irrelevant statistic...

[Anonymous Coward]

This is Ruby we're talking about... What really matters is how many of these modules "monkey patch" core classes and completely fuck up your application just by depending on them.

Re:Irrelevant statistic...

[Aladrin]

Even as an amateur, this is something I worry about. I realized pretty quickly how dangerous monkey patching is, but others seem to think it's the answer to everything. Need a special string manipulation function? Name it something generic and slap it on String. UGH.

I even saw where Rails had added a function to String that rewrote the request string. Then others started using it, because it was so useful. And then Rails changed the function. All those people using it for unintended functionality were now broken because the change they made wasn't something you'd expect a function named that to do.

That function was 'camelize' and is aliased to 'camelcase'. Here's the issue: It also converts '/' to '::'. This is completely unexpected from the name.

Now, I get that upgraded to a different version of a library will have some unexpected effects, but you shouldn't have to worry about something so basic as this.

Re:Irrelevant statistic...

[Moondevil]

As if Perl modules don't monkey patch as well...

Re:Irrelevant statistic...

[sourcerror]

I have no experience with ruby, but I guess you could monkey patch the (ancestor of everything) Object class, to give warnings when somebody tries to change methods. But I agree, that monkey patching in general isn't a good idea. I guess that's why Java and .net doesn't support it out of the box. (Of course you can have it with JVM and .net based scripting languages.)

Re:Irrelevant statistic...

[freedumb2000]

++ for your comment. monkey patching sounds good, but it's a real hassle.

Re:Irrelevant statistic...

[e70838]

I fully agree. I am a Perl programmer. I like very much the syntax of ruby. At first, it seems to be as expressive as Perl without the need of cabalistics symbols ($ @ %). But when I discovered the libraries with all the inconsistent names and all the silly aliases, I felt I can wait until they fix all that.
It is normal that people writes their own modules: the default libraries are too crappy.

Re:Irrelevant statistic...

[freedumb2000]

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.

Re:Irrelevant statistic...

[EsbenMoseHansen]

While I agree that changing the functionality of a library function underneath users in a non-backward-compatible way is bad, this has nothing to do with monkey-patching. What you describe would be the same in any language supporting library function, even if it was named "char* camelize(const char* input);" and written in C.

Re:Irrelevant statistic...

[TheRaven64]

I am a Perl programmer. I like very much the syntax of ruby.

Not really surprising. Ruby was designed to merge Perl syntax with Smalltalk semantics.

Re:Irrelevant statistic...

[Aladrin]

The String class was monkey patched with that function, and called what anyone could call it: 'camelize' and 'camelcase'. If Rails wasn't such a large project, it's likely many other projects would have monkey patched in exactly the same way. As it is, some probably do anyhow.

And it still would have been fine, if it did exactly what you think it would, instead of adding the bit about converting slashes.

Re:Irrelevant statistic...

[postmodern modulus I]

There are four main options for XML parsing in Ruby. REXML (bundled with Ruby stdlib), Hpricot (legacy), libxml-ruby, Nokogiri (very popular). As for documentation, there is rubydoc.info.

Re:Irrelevant statistic...

[Unequivocal]

Am I being overly pedantic to say that I think it's Perl semantics that Ruby copied not Perl syntax? Perl syntax as OP says includes "cabalistic symbols" and other gnarly hard to read 5 minutes after you wrote it stuff..

Smalltalk syntax on the other hand is clean and easy to read. Ruby has replicated some of smalltalk's semantics as well (ie. everything is an object) and they designed the syntax so that moving from Perl is not a big cognitive leap, but I don't really see Perl and Ruby having similar syntax in a significant way.

Not really disagreeing with you per se, but wanted to throw these observations into the mix.

Re:Irrelevant statistic...

[DragonWriter]

Am I being overly pedantic to say that I think it's Perl semantics that Ruby copied not Perl syntax? Perl syntax as OP says includes "cabalistic symbols" and other gnarly hard to read 5 minutes after you wrote it stuff..

A lot of that was kept in Ruby, though over time alternative syntax was added that better fits the Smalltalk-inspired OO structure of Ruby. Over time, the Perlisms, most of which are still supported in Ruby, have become Not Encouraged.

Re:Irrelevant statistic...

[Unequivocal]

You're totally right - I forgot about all those perlism (cabalistic characters) in Ruby. I'm not going to thank you for reminding me but thanks for the correction.

Re:But CPAN is shit

[Anonymous Coward]

A lot of Python's standard library is bordering on garbage. It's disgusting how many glaring inconsistencies and obvious bugs there are. Unfortunately, I have to agree with Zed and suggest that Python suffers from a serious case of neglect.

Re:But CPAN is shit

[ST-Clock]

There is "pythonforge" but I've never used it.

Pythonforge? Do you mean PyPI, the main repository for Python frameworks and libraries that is the default download location of the flurry of Python install tools (setuptools, distribute, pip) and that contains 12487 packages? You never used it? Good sir, you are missing a little something.

Re:But CPAN is shit

[Anonymous Coward]

It also spews files all over /usr which confuses your packaging system and any CPAN modules worth packaging are provided by the vendor.

I wish I had mod points to mod this up purely for that comment.

Prototyping and Small Projects

[eldavojohn]

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. The most notable is Twitter who I think is starting to componentize its pieces and move the high load intensive pieces to Scala. 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.

Re:Prototyping and Small Projects

[Anonymous Coward]

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:Prototyping and Small Projects

[sourcerror]

On the other hand twitter has a Java backend (Scala to be more specific), because Ruby just didn't handle well the high load.

Re:Prototyping and Small Projects

[ukyoCE]

but they will eventually switch to something else as the technology evolves, or the needs of the site change, and so on.

Unless the language is open source, and then you can change the language and frameworks to meet your needs instead of rewriting in a new language for 1 feature. Or being forced to throw up your hands when you find what seems to be a language or framework bug, versus being able to dig into the source, confirm it, and submit a patch.

Not saying changing languages is never the right solution, but with open source there are more options. That is actually how Facebook is still using PHP.

http://blog.facebook.com/blog.php?post=2356432130
http://developers.facebook.com/blog/post/358

Re:Prototyping and Small Projects

[mcvos]

Scala isn't the same as Java. Yes, it runs on the JVM, but so does JRuby. The advantage of Scala is that it still offers concise, expressive code with many Ruby-like dynamic features, but without the overhead of actual dynamic typing. And it can outperform Java in parallel processing.

Re:Prototyping and Small Projects

[Unequivocal]

I don't have first hand knowledge but I'd be willing to bet that Twitter is using Jruby to help manage the transition. It's pretty rock solid in my experience and gives you the main benefits of Ruby without the crappy-ass interpreter that Matz and co can't make run right (it has painfully slow start up and doesn't parse all that well inline as compared to other similar languages such as python).

offtopic..
I love the language but hate the implementation.. Zed Shaw sang a song about this at his last Ruby conference ever. The chorus was "Matz don't patch."

Re:Prototyping and Small Projects

[sourcerror]

NOOOOO!

"To handle the peak rates of Tweeting, 5000 per minute during the Obama Inauguration, Robey Pointer at Twitter has moved their main message queue from Ruby to Scala for improved performance. He explains the concepts behind the Twitter Kestrel project on his live journal and the more concise 1500 lines of Scala code can be seen as open source project here."

http://www.scala-lang.org/node/1008

http://blog.twitter.com/2009/01/building-on-open-source.html

Re:Prototyping and Small Projects

[Unequivocal]

I didn't say the message queue was in Ruby. I do believe that they are still using Ruby in parts of their stack, and the blog article you cite seems to support that. And though the blog doesn't indicate it, if they are using Java heavily for their queue, then I'd bet that they are using Jruby for where they are implementing Ruby still b/c regular ruby interpreter blows. If they already have enterprise java running in their environment then Jruby is a natural fit.

Thanks for the ref on Scala - interesting tech.

Re:Prototyping and Small Projects

[sourcerror]

They can use XML-RPC too. (This is just speculation too.) And as far as I know, JRuby isn't faster than regular Ruby.

Re:Prototyping and Small Projects

[Unequivocal]

JRuby had a number of performance advantages (and some disadvantages) over Ruby 1.8.x when I last looked, but looking again now, I can see that Ruby 1.9 has killed it in terms of optimizations on some basic test cases: http://programmingzen.com/2007/12/03/the-great-ruby-shootout/

http://www.rubyinside.com/the-2010-ruby-implementation-performance-shootout-3554.html

"Ruby 1.9.2 RC2 and JRuby 1.5.1 are almost joint first place for fastest Ruby implementation"

But my point was mostly that if you're already running an enterprise Java stack then running Jruby could offer a lot of conveniences and hackability to integrate into the rest of the tool chain.. But we're both speculating on all this.

Thanks for the civil dialog!

Re:Prototyping and Small Projects

[ElliotWilcox]

I have some web development skills i.e. html, css, java script etc and I have taken a bunch of java programming classes, a skill I never developed (programming in java) Do you have any recommendations for getting acquainted with Ruby on Rails? Are there any demos I can build or DIY tutorials you recommend to get started proto typing or building a basic apps to learn the basics of Ruby on Rails ? Thanks in advance for the useful links and info above

Re:But CPAN is shit

[Anonymous Coward]

I don't want to start a perl versus python war.. ok, I will., Something that python does right is provide a very complete default library.

As opposed to Perl, which provides absolutely no core modules at all. Oh, wait...

Re:But CPAN is shit

[icebraining]

It also spews files all over /usr which confuses your packaging system

man checkinstall

Re:But Python is shit due to:

[Anonymous Coward]

- Not having case statement, due to Guido's arbitrary decision making.
- Being forced to indent my code Guido's way.

Re:But Python is shit due to:

[Peaker]

Can you please show an example of indentation that's not "guido's way" and would not be accepted by Python?

Re:But CPAN is shit

[mangu]

I don't want to start a perl versus python war.. ok, I will.

I think it's funny how a discussion on Ruby drifts into a Perl vs Python war, and at this point this is the post with most answers.

Not to dismiss Ruby, but perhaps surpassing CPAN in absolute numbers does not mean everything.

I have used Perl in the past, now I use mostly Python for all quick programming and a lot of other applications, as a matter of fact I use Python almost exclusively, except for those parts where nothing but C will do. And I must say that the "batteries included" philosophy of Python is working fine for me.

Why not Ruby? In my case it's personal taste alone that made me prefer Python. All in all, I have seen many good analyses of Python vs Ruby that present good arguments for Ruby, but in my case, for my own particular uses, I found Python to be more to my taste. Simpler syntax, cleaner and easier to read for one thing. For instance, the overuse of the "end" word reminds me of Fortran, "END" what? If it isn't obvious at a glance it's wasting my time. Another common argument for Ruby is Rails, but Django has been working fine for me under Python.

In conclusion, Ruby is great, but I prefer Python. However Perl is obviously not dead, yet.

Never mind the quality, feel the width

[petes_PoV]

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.

Re:Never mind the quality, feel the width

[ascari]

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.

Quick!

[damn_registrars]

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!

Re:Quick!

[siddesu]

I would, but I use perl instead of ruby.

DLL hell

[Jay Maynard]

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

[hachete]

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.

Re:DLL hell

[rubypossum]

One of the reasons I moved from Perl to Ruby was Bundler and Capistrano. These really fix the problem of instant multi-server deployment AND upgrades. It's a beautiful thing! http://gembundler.com/ https://github.com/capistrano/capistrano

Re:DLL hell

[Anonymous Coward]

(Especially older) RubyGems has this problem, but the new Bundler stuff does a pretty good job of fixing it.

Unfortunately, Bundler is new and Ruby is old. So I'd guess the vast majority of the RubyGems repo doesn't use it. I'm not sure it's even a full 50% of the new gems using it...

Re:DLL hell

[alexkorban]

Gems don't really have to be modified to be used via Bundler. Gems have always had dependencies specified via gemspec files, and that's what Bundler uses. AFAIK, the problem Bundler has solved is dependency resolution, not gem packaging or dependency specification. That's the case for Rails apps, anyway.

Re:DLL hell

[postmodern modulus I]

There is a huge push for moving away from C extensions, and towards using FFI (Foreign Function Interface).

Re:DLL hell

[DragonWriter]

I sure hope RubyGems isn't the utter DLL hell that CPAN is.

RubyGems supports multiple installed versions of the same gem and explicit version requirements when including gems, so in principle "module version hell" can be avoided.

Re:But CPAN is shit

[sourcerror]

" Duck-typing as a very bad idea."
Both Ruby and Python does duck typing, and I guess Perl too. So I don't see your point. Scripting languages do duck typing.

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

[Anonymous Coward]

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

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

[Anonymous Coward]

i think it was pl-2-rb.rb

Re:But CPAN is shit

[sqldr]

You're right.. you can duck-type in python. The difference is that ruby encourages it like it's a good thing.

in my part of the scientific community

[Anonymous Coward]

the people who use python think it is great, and those who don't are pretty much meh but that's as you'd expect

Quality has never been a concern of Rubyists.

[Anonymous Coward]

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

Re:Quality has never been a concern of Rubyists.

[Bigos]

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.

Re:Quality has never been a concern of Rubyists.

[kill-1]

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

Re:Quality has never been a concern of Rubyists.

[SanityInAnarchy]

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.

Re:Quality has never been a concern of Rubyists.

[SanityInAnarchy]

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, "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, Nokogiri, an

Re:Quality has never been a concern of Rubyists.

[Leolo]

Most of what you said could be applied to Perl and CPAN as well. Monkey Patching? Isn't that the heart of Moose? Duck typing? That's basically all of Perl OO. I have no opinion of ActiveRecord, but I'm sure there are sucktastic ORMs on the CPAN. I also no the vast majority of the CPAN are not close to "high quality" let alone "extremely".

And I say the above as someone who uses Perl professionaly since 1995. So you could say I have a pretty large pro-Perl bias.

What would be more interesting is stats on what kinds of modules the CPAN has vs RubyGems. 1500 variations on text templating? 10 competing HTTP servers? 10 different event loops?

Re:Quality has never been a concern of Rubyists.

[chromatic]

Monkey Patching? Isn't that the heart of Moose?

Not at all. Are you thinking of a metaobject protocol?

Duck typing? That's basically all of Perl OO.

Roles provide compile-time method and dependency resolution. They're the antithesis of duck typing.

Re:Quality has never been a concern of Rubyists.

[julesh]

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

Re:Quality has never been a concern of Rubyists.

[Anonymous Coward]

And GET OFF YOUR LAWN!!

Re:Quality has never been a concern of Rubyists.

[Unequivocal]

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

Re:Quality has never been a concern of Rubyists.

[Anonymous Coward]

You're just jealous.

Re:Quality has never been a concern of Rubyists.

[postmodern modulus I]

You seem to have an outdated understanding of the Ruby community (you point out Rails-centric problems from ~2006).

The Ruby community is obsessed with testing and documentation. You cannot get +2 line patches accepted without tests accompanying them. It's common to test your projects against all the major Ruby VMs (1.8.7, 1.9.2, JRuby and Rubinius) using RVM. YARD and rubydoc.info have recently gained a significant following.

Not many developers prefer to use monkey-patching these days. It's a powerful tool, but one can avoid using it by including/extending Modules. Also, Ruby 2.0 will be introducing a new feature known as class-boxes (aka Refinements), which will compartmentalize monkey-patches to modules.

There are alternatives to ActiveRecord, such as DataMapper which has had Strategic Eager Loading (SEL) and Lazy Loading long before ActiveRecord 3 was released. But what do ORMs or ActiveRecord have to do with the number/quality of gems on rubygems.org?

tldr; Rails community != Ruby community

Re:Quality has never been a concern of Rubyists.

[afabbro]

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.

Re:Quality has never been a concern of Rubyists.

[Anonymous Coward]

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

I hadn't come across it before, and I'm having some trouble figuring out what exactly it means. Is it different from metaprogramming and mixins? Or is it just another word for the same things? Mixins and metaprogramming are generally considered good things. You get to avoid things like Java's AOP, while keeping readable and maintainable code, and updatable dependencies.

Re:Quality has never been a concern of Rubyists.

[Anonymous Coward]

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.

Tell that to Alan Kay, John McCarthy and every single LISPer and SmallTalker.

Re:Quality has never been a concern of Rubyists.

[Bigos]

I've been using Ruby since 2002, and started dabbling with Rails only this year. To be honest, Rails make me cringe sometimes. In general with version 3 things went a bit in right direction, so who knows, maybe one day more people will be happy with the framework. Some people seem to be aware of potential problems with Ruby and Rails, if you have time watch this quite interesting talk from RailsConf 2009 http://www.youtube.com/watch?v=YX3iRjKj7C0

Re:Quality has never been a concern of Rubyists.

[kmoser]

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.

Your lack of faith in Extreme Programming's agile development methodology disturbs me.

Re:Quality has never been a concern of Rubyists.

[julesh]

AIUI based on the OP it refers to adding additional methods to the built-in types (or changing their behaviour), something that you can achieve in both ruby and javascript but not most other languages.

Re:Quality has never been a concern of Rubyists.

[fusiongyro]

I realize this is mostly a diatribe for the sake of being controversial or perhaps preaching to the choir, but I believe you make a couple of good points in what you say, mixed in with few lies.

I am, first of all, not at all convinced that monkey patching has been a systemic problem in Rails. As far as I'm aware, there has been one situation in which the standard library acquired a method that had been patched in by ActiveSupport, leading to a rushed release to support a newer version of Ruby. If you look at the monkey patching situation in Rails today, mostly you see a bunch of handy methods in ActiveSupport and very little elsewhere. These are methods like pluralize, human_size, megabytes, etc, that enable you to write conventional code like "3.days.ago" and have it converted to a time object of some sort. Especially after the Merb debacle, emphasis in the core has been on solid interfaces and APIs, not magic hidden methods that can be magically overridden.

This does not fix what I consider to be a principle folly of Rails, which you point out: ActiveRecord. The emphasis in Rails is on programmer productivity, database be damned. Emphasis on MySQL also. I used to use a library called RedHillOnRails which furnished a lot of helpful stuff for PostgreSQL developers such as making the database generate foreign key constraints, using the database's constraints to avoid duplication in the ActiveModel code, and so forth. This library isn't really supported under Rails 3, which points to one of my primary objections to Rails and (to some degree) the wider Ruby community, which you allude to in talking about large amounts of software. There is a strong emphasis in this community on code heroics and so much code winds up on Github or someone's blog. It gets released, not particularly well-documented, and then the onus is on you to follow the person on Github or follow their blog, make sure you stay up-to-date when they tell you whatever's in the repository is stable, keep track of who is the current chaperone when the first guy loses interest (will_paginate is another example of this), and then you have to not be married to these libraries because when the next version of Rails comes out, you'll wind up throwing them away and using something else anyhow.

In the Java world, the APIs are rather stable, and the busy work is doing all of the "@Override public static final" and repeating yourself in the variable declarations (MyFoo foo = new MyFoo(...)). In Ruby/Rails, the busy work is staying up to date with APIs that constantly change and code that constantly changes hands.

The ORM situation is somewhat better in Rails 3, since you can now plug in Sequel, which does a much better job of staying out of your way, but lots of libraries expect you to be using ActiveRecord under the hood. Devise is a good example. It does everything and is simple to use, but if you're using Sequel, well, there's two people doing that and we got it to work through a bunch of uncool monkey patching. I have to ask myself, would I rather write this code myself or monkey patch it into working? Usually at the time, my answer is monkey patch it into working, but then it breaks a few months later and I don't have the stamina to keep making it work.

The ORM situation isn't any better in Java land though. Hibernate is a complete piece of shit. I've lost months of productivity to it and it doesn't perform for a damn because it flat-out does not make sense. It sounds like we're kindred spirits on this point though; SQL is my ORM.

Regarding testing, I never caught the testing bug myself. I blame Haskell, actually, which has made a lot of unit testing seem like busy work even when I'm using languages that can't detect the same range of errors at compile time that it can. However, I will say that out of all the Rails users I know, I am definitely the slacker when it comes to testing; one friend is very fond of test/unit and another has been an RSpec/BDD proponent for a long, long time. The problem with Ruby and Rails isn't a lac

Re:Quality has never been a concern of Rubyists.

[ToasterMonkey]

Monkey patching can be a very powerful approach, if used properly. It makes possible to write very readable code.

Uh.. operator overloading can lead to some very "readable" code too, and they both lead to maintenance nightmares. Hey, if you're the only person that will ever need to read your code and you always remember why you did everything the way you did it, then you're in the clear.

Re:Quality has never been a concern of Rubyists.

[Bigos]

Does it mean, that one day, some Rubyist will write a tool to scan your source looking for monkey pathing? Some Java/C++ editors have tools to take care of searching for operator overloading to make your job easier. No matter how hard you try you will always have problems with program maintenance. Does it mean that someone else has to use less powerful, and less expressive language? Or rather do you think your code should be commented properly, so there are no problems mentioned in your post?

Re:But CPAN is shit

[icebraining]

How can you _not_ duck type? Python doesn't have static typing at all...

Maybe you mean something else?

According to modulecounts... but then again...

[mr_mischief]

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

Re:According to modulecounts... but then again...

[Anonymous Coward]

Ok, I'm a Perl programmer, but...

* CPAN also has applications (some put in App:: but not always).

* CPAN also has quite a lot of Acme:: modules, which, while cute, are practically useless.

* CPAN also has modules containing just a couple of lines of actual code.

* There are loads of crap too on CPAN. Not all distributions have test suites, proper metadata (unspecified dependencies), documentation, or even proper abstract line. A majority portion is no longer maintained/updated, some even no longer builds.

* CPAN doesn't even have: download counters (due to distributed/filesystem nature, but why does search.cpan.org itself resist having download counters?)

* CPAN still doesn't allow listing multiple authors/maintainers.

* The default CPAN client still can't install non-newest version of a dist.

Re:According to modulecounts... but then again...

[postmodern modulus I]

The old rubyforge.org (based on GForge) had many of those features. rubygems.org (based on the gemcutter) is still rather new, and could use some more features (ranking would be nice).

Re:But Python is shit due to:

[blincoln]

Can you please show an example of indentation that's not "guido's way" and would not be accepted by Python?

I can't speak for the anonymous grandparent, but the last time I played around with Python, it wouldn't accept anything that wasn't indented in a very specific way. Something like one tab per level of curly braces, and the curly braces also had to be used in a very specific way. I can't remember if it was Visual Studio-style (both opening and closing braces on their own lines) or not. It was more or less the way I indent code anyway, but the fact that whoever wrote the language micromanaged whitespace instead of leaving it up to the developers made me decide not to use it again.

I hate coding in the old-school style where the opening curly brace is on the same line as the statement that triggered the opening of the brace (it makes it hard for me to find the opening brace that matches a particular closing brace), so who's to say the language maintainers wouldn't arbitrarily start requiring me to use that style at some point? On the other hand, there are plenty of people who love using that style. The code is functionally the same, so who cares? They can code their way, and I can code mine. In any reasonable language, at least.

Re:But CPAN is shit

[sourcerror]

Are you sure you're not confusing it with monkey-pathcing?
As Python doesn't enforce types in function calls, there really is no way to get around duck typing.

quantity vs quality?

[omission9]

Since I know members of both the Ruby and Perl community I can pretty much guarantee CPAN is the far more
functional and stable body of code!

Re:But CPAN is shit

[Jimmy King]

It's fairly straightforward where modules get installed. I personally find it great. When the distribution handles their pre-packaged modules sanely, it makes it very easy to tell which modules were installed by the distro and which from cpan. With python, at least on Debian, distro modules and pypi modules all get dumped in the same place. That gets a bit messy to me.

I also prefer CPAN with a more centralized repository for the code. Pypi seems to install crap from all over the place, it could pull from someone's personal website, sourceforge, wherever. It seems to me that CPAN is more likely to be more resilient and consistent than Pypi as Pypi ages and old modules stop being hosted and the centralized aspect gives at least a better possibility of having some sort of central checking for authenticity and a number of other possibilities that may or may not actually be happening - but they at least could.

If you've ever been involved in large scale Perl development, you'd also quickly discover that your distro of choice may not actually provide every useful Perl module. I've got a document I maintain for setting up new installations of our platform that includes a list of which modules to install from the apt repository and which modules need to be installed from CPAN either due to not existing in apt at all or needing functionality not included in the much older version of the module that is frequently included with Debian. It's not a huge list, but it's probably 10 modules that I install from CPAN, some of which install a few others as dependencies, although to be fair to hose dependencies may be included in apt as I just tell CPAN to auto install them currently.

Good choice

[bill_mcgonigle]

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.

Re:Good choice

[TheLink]

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

Re:Good choice

[bill_mcgonigle]

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.

Re:Good choice

[TheLink]

Just because openssl is present does not mean that perl LWP will have TLS/SSL/https support. For that you need Crypt::SSLeay.

One could give up on LWP and connect by using "openssl s_client -connect dest:port" but that means reimplementing a fair chunk of what LWP does and adding lots of other stuff.

Re:Good choice

[bill_mcgonigle]

Just because openssl is present does not mean that perl LWP will have TLS/SSL/https support. For that you need Crypt::SSLeay.

Right, but the question was about when you were bundling your modules rather than using the system modules.

Re:Good choice

[TheLink]

Well the OP did say "shipping a product based on CPAN stuff,".

So if the product requires https, then it might need LWP (which is included on many linux distros but not in some!) and Crypt::SSLeay (which is not included on many platforms).

Then from what I see, bundling Crypt::SSLeay means building multiple bundles for each linux distro that's "different".

So yes, a perl bundle will work, but if it is not "pure perl" it's likely to only work for one distro.

Re:Good choice

[Anonymous Coward]

What theyre shipping often precludes using some of the more useful things like modern versions of DBIx::Class or Catalyst. Still an option, but painful.

And shipping an entire build env is an option, but it can lead to some interesting licensing issues. Luckily most(all?) of CPAN is perl artistic, but try explaining what that means to the company you just wrote a webapp for.

Re:Good choice

[bill_mcgonigle]

Well the OP did say "shipping a product based on CPAN stuff,".

Right, modules available from CPAN (rather than re-inventing the wheels). You seem to be implying he meant, "automatically downloading the latest version from CPAN and expecting it will 'just work'," when he said, "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."

So, his LWP is built with Crypt:SSLeay if that's a requirement.

Re:But CPAN is shit

[sqldr]

This is ok on a single machine, but if your entire system of 90+ servers is fully configuration-managed, you can't automate this. Perl, PEAR, pythonforge, ruby gems and any other suchlike are BANNED :-) I've written a python script to convert pear tarballs into rpms :-) I trust rpm and that is the only package installer on my systems.

Great, now let's work together.

[bill_mcgonigle]

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

Re:Great, now let's work together.

[Eivind Eklund]

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.

Re:Great, now let's work together.

[rubycodez]

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.

Re:Great, now let's work together.

[bill_mcgonigle]

I don't think the state of the art is a fixed measure. Time will tell, but Perl 6 is a specification, not a product. Rakudo Perl, the best implementation to date, is written in PIR, the parrot language. It's not done yet, but then again that's what I thought of Ruby when I first started using it in 2003. I still think that, btw.

Re:But Python is shit due to:

[lattyware]

Uh... sorry to burst your bubble, but there are no curly braces in python, well, not for indicating code blocks, anyway.

Re:But CPAN is shit

[Anonymous Coward]

There's an easy way to get around duck-typing - inherit.

You inherit from the base class and write any damn member function you like! Those functions become members of YOUR class, not somebody else's.

Re:But Python is shit due to:

[TapeCutter]

Python doesn't use curly braces for compound statements, that's what the indents are for and why it's important to get them right. Personally the indent thing is the only part of Python that really irritates me since some editors can fuck up the tabs beyond repair. I would love to see Python use C style compound statements but even without that it's still the best programming glue I have used.

Re:But CPAN is shit

[Jimmy King]

True, it would get out of hand with a large number of servers. Doesn't matter whether you're using pypi or CPAN there, though, they both suffer from the same problem when it comes to manually managing the configuration.

I'd love to have a more automated system like you've got going. Just don't have the expertise at the moment or the time get get the expertise. Management keeps letting people go and as much as I and upper management here don't like to admit it (although for different reasons), I just can't be an expert on everything.

I suppose once it becomes necessary, rather than just nice to have, I'll get on with sorting something like that out... of course with any luck I'll have moved on to somewhere that it's just not my job to be an expert on configuration management in the first place long before I hit that point here.

News at 11...

[offerk]

So some random *Ruby* web developer (who doesn't even understand the structure of CPAN) thinks *Ruby* is getting bigger than Perl... news at 11...

Re:But Python is shit due to:

[lattyware]

Really, that's a flaw with the editor, not the language. What we need is to drive flexible tabstops and get everyone using them. The whole max-width-tabs/spaces thing is a rediculously outdated way of doing it.

Re:But CPAN is shit

[TheRaven64]

Not just scripting languages. Objective-C does too, and is a statically compiled language.

After 10 years?

[Viol8]

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

If thats the case then either you never learnt it properly in the first place or the language is so hopelessly over complicated that it really needs to just go away and die peacefully. Its a programming language, not a dissertation by Wittgenstein - it should be logical, clear and simple.

Re:After 10 years?

[Bill, Shooter of Bul]

Ok, so we can cancel all Math classes after 10 years right? Because anything logical should take less time to completely learn and understand. Lets face it: Math professors are lazy bastards that don't deserve their research grants. /sarcasm

Re:After 10 years?

[Anonymous Coward]

No. But there is a reason roman numerals fell out of use.

Re:After 10 years?

[sdb6247]

This is the dumbest thing I've seen anyone say on Slashdot. Yes, you're so right. If you're still learning something after ten years, it must suck.

Re:After 10 years?

[metamatic]

If thats the case then either you never learnt it properly in the first place or the language is so hopelessly over complicated that it really needs to just go away and die peacefully.

It seemed pretty clear to me that Perl 6 was going to be a case of the latter, which is why I personally jumped ship to Ruby.

Re:After 10 years?

[Viol8]

If you still learning THE SAME FUCKING THING after 10 years then yes , it DOES suck. Or you do.

Re:After 10 years?

[Viol8]

Christ , who modded that crap +4? If you can't tell the difference between the entire realm of mathematics and a scripting language whose syntax can be summed up in 1 small book then perhaps you should stick to an abacus.

Re:After 10 years?

[BlueStraggler]

There is a difference between complicated and expressive.

C++ is complicated. C is expressive. It's no coincidence that C used to have the same reputation as Perl for having too many ways to skin the same cat, hard core geek appeal, and obtuse, punctuation-heavy syntax (witness the IOCCC).

Re:After 10 years?

[Bill, Shooter of Bul]

Definitions of analogy on the Web:

+ an inference that if things agree in some respects they probably agree in others

+ drawing a comparison in order to show a similarity in some respect; "the operation of a computer presents and interesting analogy to the working of the brain"; "the models show by analogy how matter is built up"

Re:After 10 years?

[ThePhilips]

Perl is free form and allows a multitude of approaches to solving problems. One can learn all the syntax and functions and utilities easily by reading through perldoc - just like documentation for any programming language for that matter.

But that would not teach them programming.

The fact is that one constantly advances as a software developer (*). Yet the very same language easily adapts to all the new paradigms, allows trivially to express new ways to code -after all the years- is pretty amazing fit.

Or to put it other way: in Perl number of ways you can do something is equal to the number of Perl programmers. And new programmers always bring something new, something worth learning.

Read on to enlighten yourself.

(*) If you do not - then change the job. Learning new stuff is a part of the job definition.

Re:After 10 years?

[Viol8]

So what. You can say exactly the same thing about every programming language ever invented. YOu think all creative and original development in C++ is done and dusted?

Re:After 10 years?

[ThePhilips]

You can say exactly the same thing about every programming language ever invented.

Even BASIC??? You make me laugh.

Specifically the C++ is yes, mostly done and dusted. It is a static language: it is rigid and inflexible. That's what for we actually love it, but it is going to be replaced (and it needs to be replaced) because it incorporates the paradigms which were new 20 years ago. For modern programming, C++ is often too restrictive. E.g. implementing analogue of ObjC message dispatch is possible only with intricate low level hacks in asm (or using a 3rd party library which already does that for you). Implementing Perl's eval{} is flat out impossible.

Re:After 10 years?

[Viol8]

"Even BASIC??? You make me laugh. "

Yeeees , even basic. I've seen chess written in Basic FFS and I'm not talking VB.

"For modern programming, C++ is often too restrictive."

Sorry , what exactly is "modern programming"? If you mean bloated with a load of handholding for lego brick style programmers then you're probably right. Otherwise its a perfectly fine tool.

"E.g. implementing analogue of ObjC message dispatch is possible only with intricate low level hacks in asm (or using a 3rd party library which already does that for you)"

Oh please. Message dispatch is just a trendy name for runtime set up of function pointers. Go read about dynamic library objects you clueless gimp.

"Implementing Perl's eval{} is flat out impossible."

Care to remind us what Perl is written in?

Re:After 10 years?

[Monkeedude1212]

If you can't tell the difference between the entire realm of mathematics and a scripting language

If you can't humbly admit that learning a language is far more than just the syntax - you should stay away from software development.

Knowing how to make a program run in Perl IS trivial, you can learn it in a day with 1 book, for sure.

But learning the neat tricks to actually leverage the power each language has is something of a lost art.

I thought you would've picked that up by Happy's post.

I think the number on cpan.org might be wrong

[xenoterracide]

CPAN Testers reports over 21000 http://stats.cpantesters.org/ I think the number on cpan.org might older... and updated less often. Guess ruby has a ways to go yet.

Re:But CPAN is shit

[Vanders]

This is ok on a single machine, but if your entire system of 90+ servers is fully configuration-managed, you can't automate this.

To be totally accurate, Puppet has support for managing Ruby gems. You're right about the others, although one could probably also add PEAR support to Puppet.

Re:But CPAN is shit

[sqldr]

I believe the "Camel" has a few lines from Larry Wall saying "you don't have to know the whole of perl to use perl". Not the same with puppet.. there's booby traps everywhere. I have dev/qa/stage/live environments, so naturally I was passing this around as $environment

Turns out that $environment is a hard-coded puppet "fact", and now I need to use it. One massive perl -p -i -e coming up!

btw. The puppet tutorial will leave you none the wiser. You have to just spend time with it and use it for practice. How I did it: spent 4 months writing the config, then rm -rf and started all over again :-) Second attempt took 3 weeks.

Re:But CPAN is shit

[sqldr]

btw.. one of the wonderful things about automated systems: devs get root. WHAAAAT? yep! less tickets for us, and if they completely screw their server up (this has never happened) I can rebuild it with a mouse click

Better still is the tickets you get actually work. They've already tried the change on their dev box, so when they want an apache change to qa/stage/live, they send you stuff which actually works, rather than "could you try this Rewrite please?" and sending the ticket backwards and forwards until you get something which works. It's bliss.

Re:But CPAN is shit

[sqldr]

o be totally accurate, Puppet has support for managing Ruby gems.

And thus my later comment about how puppet is full of booby traps :-) I've been using puppet for 2 years and stood up to give a talk about it (well, architecture design in general) and I didn't know that! Either way, I've got a script to convert gems into RPMs, so I don't need it.

The more, the worse

[Anonymous Coward]

You say that like you think it's a good thing.

Re:But CPAN is shit

[osvenskan]

Pypi seems to install crap from all over the place, it could pull from someone's personal website, sourceforge, wherever.

A minor quibble -- PyPI doesn't install anything from anywhere. PyPI stands for Python Package Index, the key word there being "index". It's a catalog that tells you where to find packages. Once PyPI points you to the package, it's up to you to decide whether or not you want to install it.

Quantity versus Quality

[bart416]

Ruby might have the quantity. But does it have the quality of Perl modules? I seriously doubt so. Many Ruby programmers aren't nearly as experienced as the Perl folks. Ruby will generally be used by people who think it's cool cause of it's "OO-ness" (Don't ask me why that's supposed to be a huge advantage, but that was somebody's pro-Ruby argument once). Perl on the other hand is often used by experienced system administrators. At that point you clearly see a difference in target group. Additionally Ruby isn't as nearly wide spread as Perl. Keep in mind Perl is one of the first things that gets ported to a new platform along with C/C++ compilers and other tools meaning it'll always stay ahead of Ruby no matter how it gets.

Re:Quantity versus Quality

[rubycodez]

The perl that gets ported is just stinky old Perl 5.x, porting doesn't add new features.

The libraries of all the scripting languages have crap, cruft, and redundancies.

You can write great code or crap code in any of the scripting languages, and choose great libraries or horrible ones.

Interesting new useful constructs are more likely to be found in Python and Ruby than in Perl 5.

Re:Quantity versus Quality

[bart416]

Great, a ruby fan boy... Where did I claim porting adds new features? I'm saying porting is one of the reasons Perl became so wide spread. Additionally Perl 5.x still receives updates so I wouldn't call it old either. And Perl is a mature language that won't see much changes anymore at this point, get used to it. If you want new and shiny Perl really isn't the language for you. If you want powerful syntax, the ability to quickly write code that will still perform well then Perl really is the primary choice. Perl can in fact beat Java in performance on certain areas to give you an idea about just how damn fast it is. Ruby isn't even close to either in terms of performance. And sure many things in the CPAN archive are filled with duplicates. But again lets look at the quality of the code. Writing something in Perl takes a lot more skill than writing something similar in Ruby as such the code produced by the average Perl "programmer" is statistically going to be better. Again something you will have to accept. And Perl code will never look nice, again get used to it. Perl is a contest about how much you can put in a single line. Ruby is something people use to mess around in. Whenever a project becomes serious they have to start stepping away from Ruby cause it becomes a hassle to maintain the code. Performance drops like a brick and scaling becomes rather complicated compared to languages like Perl, PHP, Python and others. For all its flaws I'd still rather write things in Perl than in Ruby; Cause in the end of the day I know if I need to quickly do something Perl is up to the job every single time. I have yet to run into a case where Perl failed to deliver the results. Ruby and Python on the other hand...

Re:Quantity versus Quality

[rubycodez]

Perl 5 has lost almost all of its share of powering the web, http://trends.builtwith.com/framework/Perl

Scalable code can be written in any language, that's a question of architecture not a function of language choice. Any scalable algorithm can be realized in any language.

Loading as much as possible into a single line is a recipe for hard to maintain and buggy code.

Re:But CPAN is shit

[sourcerror]

It'll be resolved the same way during runtime. There's no static typing in Python, even classes/instances can get new methods during runtime (that's called monkey patching; and I guess they can lose them too). See metaclass protocol.

More useful metric:

[Ant P.]

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

Whatever happened to RAA?

[Anonymous Coward]

It's still there, but there are much less activity. Do "proper" Ruby libraries need to be registered on both? Are there current projects that are still RAA-only? Are there clients for RAA?

Re:But CPAN is shit

[Jimmy King]

Well, technically I'm a dev anyway. I just pretend to be a sys admin, dba, and support guy because they've fired everyone else.

It would drive me nuts going back to a system where I have to ask someone else to test stuff that may or may not work all the time rather than just doing it myself.

Re:But Python is shit due to:

[cervo]

Maybe he is referring to the C implementation of Python which would be implemented in C and thus have curly braces....

Re:But Python is shit due to:

[cervo]

If you are referring to the C implementation of Python you might want to clarify that. Most people seem to think you are referring to the Python language which doesn't have curly braces.

I am assuming you are talking about C Python language implementation.

Half of them are fart modules, I bet

[revlayle]

*facepalm*

Speed of light

[goombah99]

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.

Re:Speed of light

[Anonymous Coward]

I agree. Python is like a shaved pussy. Sure, it's exciting at first, but I prefer a landing strip so I know I'm not fucking a 12-year old. As for ruby -- have you ever seen hairy asian pussy? You might look at it, but only because it's so disgusting it demands to be looked at. In summary, I like pussy,

Re:Speed of light

[Anonymous Coward]

I'll never quite think if python's clean look in quite the same way again thanks to you.

Re:But Python is shit due to:

[lattyware]

cpython is the interpreter and compiler, not some kind of amalgamation of C and Python.

Re:But CPAN is shit

[sqldr]

hehe.. my original post is now -1 flamebait :-D I guess the truth hurt too many people!

Re:But Python is shit due to:

[cervo]

I'm sorry I meant http://en.wikipedia.org/wiki/CPython. Basically the the python interpreter/compiler is implemented in C. So basically while working on the python implementation, there are curly braces due to the C. I don't mean some amalgamation. I mean perhaps he is referring to Guido's rules for contributing to CPython in which case the contributions would be in C.....

Re:But CPAN is shit

[sqldr]

Don't ever get a job in a big corporation. It sounds like politics isn't your thing :-)

Re:But Python is shit due to:

[Unequivocal]

Good point on the braces thing.. But I could never get past the concept of white space is significant in Python. For the very trivial reason that I use unindented code for debugging inside functions and it makes it very easy to scan quickly down a page to remove that debugging code when it's no longer in use. Totally trivial but also totally integral to how I like to work and python forces me to abandon it.. At least I couldn't figure out how to work around.

You sound like you know python and I wonder if you have any reflections on whether I'm a ninny, have a reasonable point, or other.. :)

Re:But Python is shit due to:

[Anonymous Coward]

The whole max-width-tabs/spaces thing is a rediculously outdated way of doing it.

Yep, it has been diculous over and over again.

Anyone still arguing about it is open to ridicule.

Re:But CPAN is shit

[sqldr]

To everyone who marked this as flamebait.. I guess the truth hurts. Computer science and "managing complexity" are things that will never occur to someone who thinks perl is anything more than a temporary solution to a big problem which it didn't solve.

Re:But Python is shit due to:

[lattyware]

Well, I get why you'd have a problem, but I don't see that as a problem with Python. Using indenting to specify code blocks has a number of advantages - it makes sense, it's quick and easy, you generally do it anyway, it removes clutter from your code, etc...
The answer to your problem is to replace your debugging system with another one. Maybe an IDE that allows you to mark segments of code as debug code, using comments, or some other such system.
All I can really say is that I love Python having used it for some time. The design of the language tends to make a lot of sense, and is tailored towards a lot of ease of use for the programmer. If you are very used to other languages - and doing things to work around their limitations, Python can seem alien and annoying - but that's mainly because there is a better way to do it.
I know people don't like having a way to do something dictated to them, but it really does make for a great language when you are using it.

Ruby has been extremely good for me

[Steeltoe]

I'm using Ruby for a personal project of mine going on for about a year now, semi-fulltime. I'd like to add that I've been programming since I was 8 years old, and have a grasp of most common procedural languages except LISP and functional languages.

If you don't like Ruby because it's too powerful for you, fine. However for my needs, Ruby has really made my system of several processes faster to create, more dynamically flexible than I first envisioned, easier to extend and refactor. In fact, my experience has been so positive, that I have almost nothing negative to say about Ruby and ActiveRecord. This is because whatever hurdles I met, I overcame them, and often enhanced my system further by learning to do things better from the higher-level and down.

What you list as weaknesses of Ruby, as a quite experienced programmer, I see as benefits:
1) "Monkey patching": I have a few files where I extend basic objects like String, Object, etc., for use with serializing and mathematical extensions I required. No I don't "monkey patch" unless required, but native float is just too horrible, so I had to modify BigDecimal to make the core functions easier to use. I also combined Msgpack (faster serialize, but doesn't support all Ruby types) and Marshal (native serializing in Ruby), to be able to serialize everything over the faster Msgpack implementation as strings of Marshal. It is faster and more compact than just using Marshal. ActiveRecord was extended because I needed lightning fast mass "insert-or-updates" to DB, for which I used temporary db tables. A very simplistic one-liner is all that is required to update any of my tables with arrays of objects. Neato.

Now, the files and lines where I extended library and core functionality is not too great, and it allowed me to stich together already accessible functionality to improve performance, and making things more readable and accessible at the same time.

For very little effort, "monkey patching" enabled me to extend my very programming environment and libraries, something which in many languages are not possible.

Of course, when abused or misunderstood, this can be negative, just like a pistol is harmful in the hands of a child. When upgrading, of course, I'll need to review and test the code to see if something's changed. But these are very small drawbacks for me, and I have minimized and compartmentalized the code.

2) Duck typing: After using Ruby, I'm on the other side of the fence. I now see absolutely no reason to declare types anywhere. What I did instead is to create standard-code to dynamically check incoming arguments of all functions. That way, I can have a sort of one-sided contract behaviour, checking for *whatever* I want in the beginning of the function using instance_eval(), and save myself all the troubles of static types altogether, while enhancing my system at the same time.

I realize the standard Ruby libraries are missing such functionality, and also the efficient error-handling routines I created, but once you have such functions in place (what you need), I see no reason for static types. In fact, getting rid of types allows for more flexible arguments and handling, better fail-checks and faster development altogether. If something is wrong, often my argument- or paranoia-checking code is picking it up instantly. Neato.

3) ActiveRecord: Yes, it's ORM, but only if you want to. You can use db-depdendent, direct sql if you like, or get faster queries using arrays of arrays instead of the more general ActiveRecord objects. What ActiveRecord has done for me, is save me from endless work with SQLs, only to change them again and again. I've also extended the functionality of ActiveRecord, to deliver fast insert-update operations. If I were stuck with creating dozens of SQLs, I would probably have missed that opportunity to optimize. Because ActiveRecord freed me, but didn't bar me, from the low-levels, I was able to optimize more from the higher-level down.

Another thing ActiveRecord has done, is make my

Re:But Python is shit due to:

[lattyware]

I see - well, most people wouldn't really refer to a problem with the code behind the implementation of Python as a problem with Python exactly. And in that case, most projects have a standard on how to format code - and that makes sense, it makes projects more readable and easier to contribute to.

Re:But Python is shit due to:

[lattyware]

Ugh, I always make that same error. Spelling has never been one of my stronger points.

how about

[unity100]

you hand in your /. user id and go back to digg ...

zealot modding

[unity100]

someone please mod the parent up to proper score. some moron modded it down, despite it stated actual facts. indeed, twitter was on rails, but when they saw that it was creating more problems than it was worth, they changed it.

Re:zealot modding

[mini me]

Twitter is still on Rails. Some backend processes that would not have never used Rails in the first place are written in Scala, but which massive scale project doesn't use a number of different languages to make it all work?

Re:zealot modding

[unity100]

a lot of major websites that are using php as of this moment.

Re:zealot modding

[mini me]

Which major website has an entire application stack written in PHP? Honest question.

Facebook, for example, is known for their PHP use (if you consider HipHop to be PHP), but they use Java, C++, and Python where Twitter uses Scala.

Re:zealot modding

[unity100]

photobucket.com wikipedia.org sitepoint.com archive.org https://www.capitalone.com/

Re:zealot modding

[mini me]

Point taken. Although, you have raised and interesting point about scalability in that it has a lot less to do with the language and more to do with what you have to scale. Wikipedia, for example, serves most of their content out of Squid, meaning that the PHP code has to do little work, relatively speaking.

Archive.org uses Java, if not other languages, running behind the scenes. They are definitely not PHP top to bottom.

I am skeptical that Capital One really run their entire application on PHP. Financial institutions are usually tied into old legacy middleware written in non-PHP languages, if not for performance reasons, because they have been in business longer than PHP has been around.

Not really familiar with the others, so I'd love to read more about their infrastructure if you have some info.

I think for the purposes of this discussion, we can ignore the usual components that are not written in PHP like web servers and databases, but components that are written in house to support the app are fair game, otherwise, Facebook is all PHP and Twitter is all Rails.

Re:zealot modding

[unity100]

Wikipedia, for example, serves most of their content out of Squid, meaning that the PHP code has to do little work, relatively speaking.

php has its own caching modules. it can take place of other caching methods.

Archive.org uses Java, if not other languages, running behind the scenes. They are definitely not PHP top to bottom. I am skeptical that Capital One really run their entire application on PHP. Financial institutions are usually tied into old legacy middleware written in non-PHP languages, if not for performance reasons, because they have been in business longer than PHP has been around.

your approach is missing logic in regard to integration realities. "top to bottom" is an impossibility in which an app needs to go outside the web for doing anything. for example, a shipping company linking their web presence to a system that tracks the movement of cargo trucks to allow real time watching of where someone's cargo is at that point in time, cannot go all the way php from top to bottom.

actually its possible, if the servers providing the satellite/gsm connectivity in gsm towers or provider are set up with internal webservers, php can run on them and do the service. but, that would not be optimal, and the infrastructure is not built that way.

currently the only thing that is holding php off these kind of infrastructures are the software infrastructure issues. closed source vendors have long ago seeded these infrastructures with their own software, and these hardware were made to run with them.

if it was otherwise, php already has a mind boggling array of modules and extensions to do practically almost anything. you just need to provide the infrastructure.

Re:zealot modding

[mini me]

your approach is missing logic in regard to integration realities. "top to bottom" is an impossibility in which an app needs to go outside the web for doing anything.

Where do you draw the line? If we are only talking about the technology that generates the content, Twitter is a Rails app through and through. Absolutely no Scala, or any other language, is involved there.

You said earlier that Twitter is no longer a Rails app because they added Scala middleware. Yet, some of the sites you mentioned also use middleware written in other languages. Why do they get to keep the created-in-PHP status but not Twitter?

I guess I just do not understand where you are going with this discussion as it relates to PHP. If Twitter was written in PHP they would probably have still used Scala behind the scenes, just as Facebook uses Java, C++, and Python behind their PHP code. The truth is that virtually every computer language can generate HTML without trouble, even at massive scale.

Re:zealot modding

[unity100]

You said earlier that Twitter is no longer a Rails app because they added Scala middleware. Yet, some of the sites you mentioned also use middleware written in other languages. Why do they get to keep the created-in-PHP status but not Twitter?

twitter is doing what it can do with rails, with scala instead. so, they are actually transplanting.

in the case of examples i pitted for php websites, they are not using anything other than php, where they can. in the examples i have given, the websites/services are not using anything else than php for things that can do with php given the technicalities available. ie, for their backend, they are using php. but, they are not using php for the cellular tower server that routes messages.

Re:zealot modding

[mini me]

twitter is doing what it can do with rails, with scala instead. so, they are actually transplanting.

How so? Twitter is using Scala to power their message queue. Rails was never designed for message queue applications, and not even Twitter used Rails in that context. Ever. Rails is a web application framework and Twitter continues to use it in that context, as they have always done.

Re:zealot modding

[unity100]

http://www.google.com/search?q=php+message+queue+application&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a

Re:zealot modding

[mini me]

It is no surprise that you can implement a message queue in PHP. Unlike Rails, PHP is a programming language. Implementing a message queue in Rails would be akin to implementing a message queue in CodeIgniter or CakePHP. Though, comically, the links in your Google search:

1. talks about using MySQL as the message queue
2. talks about RabbitMQ, written in Erlang
3. talks about beanstalkd, written in Ruby
4. talks about beanstalkd, written in Ruby
5. is unrelated to network message queuing
6. talks about JMS, written in Java
7. talks about Amazon SQS; language unknown, but probably not PHP
8. talks about using MSMQ (Microsoft Message Queue); language unknown, but probably not PHP
9. is unrelated to network message queuing
10. talks about using ActiveMQ, written in Java

To be fair, #3 and #7 do also talk about Dropr, which is written in PHP. However, I believe it does show that PHP is not a very strong contender in the message queue arena.

According to Twitter, they dropped Starling, their Ruby (not Rails) message queue, because they found edge cases to be too difficult to code around. The Scala language provided features to make those tasks easier, thus improving productivity and the service as a whole. Kudos to Twitter for looking for the best language for the job, not just sticking with what they know.

Re:zealot modding

[unity100]

Unlike Rails, PHP is a programming language.

isnt that the point, already ? people are pitting rails as a programming language.

However, I believe it does show that PHP is not a very strong contender in the message queue arena.

contender, and future leader. just like how it happened with a lot of other things. all it needs is people using more and more. rest of the hardware and infrastructure will follow

According to Twitter, they dropped Starling, their Ruby (not Rails) message queue, because they found edge cases to be too difficult to code around. The Scala language provided features to make those tasks easier, thus improving productivity and the service as a whole. Kudos to Twitter for looking for the best language for the job, not just sticking with what they know.

that is the thing youre missing. it doesnt matter what you are doing - if you are doing ANYthing for the long run, any 'framework' that allows you create things fast will become a burden in future. it will either incur high load, or make further modification increasingly harder. and inevitably a point will come in which you will see that some low level operation is not possible or is infeasible with the framework you are using. that is why i argued for php. because, apart from things that require machine code, it is suitable for any kind of service/integration we are using on internet and the things it can integrate.

Re:zealot modding

[mini me]

isnt that the point, already ? people are pitting rails as a programming language.

I don't know anyone who considers Rails to be a programming language.

contender, and future leader. just like how it happened with a lot of other things. all it needs is people using more and more. rest of the hardware and infrastructure will follow

There is nothing holding back PHP in message queuing. Why didn't Twitter choose PHP instead of Scala? Surely the popularity of PHP would have made the move even easier?

that is the thing youre missing.

What am I missing? Ruby is not a framework, it is a language. It will not burden you any more than PHP, Python, C, C++, Java, Erlang, etc. will. Every language comes with pros and cons. Twitter says, even after the Scala move, that Ruby is wonderful for web-related tasks.

Re:zealot modding

[unity100]

I don't know anyone who considers Rails to be a programming language.

just read the comments made to this article. you may see that some even go beyond that in their zealotry.

There is nothing holding back PHP in message queuing. Why didn't Twitter choose PHP instead of Scala? Surely the popularity of PHP would have made the move even easier?

im not knowledgeable in details of message queueing. yet im sure there are issues of nativity with software/hardware.
....
i think we discussed long enough.

Re:But CPAN is shit

[Jimmy King]

Yeah, I've been in the big corp. environment earlier in my career. Definitely not my preferred environment, although at least at the lower levels I can deal with it. I much prefer the more mid-sized company setting... small enough that I feel like what I do and say matters, but just big enough to not have to cut too many corners or scrap good ideas/projects constantly due to lack of resources. The place I work at was there once upon a time.

Re:But CPAN is shit

[Jimmy King]

Meh, screw those people. Everyone has their own preferences based on their experience and current needs. Nothing wrong with voicing them and explaining why.

Re:But CPAN is shit

[Anonymous Coward]

The Ruby Gems provider has been documented for as long as I can remember, long before I was actively using Puppet in production. Your failure to read the documentation does not mean Puppet "is full of booby traps", sorry.

Upgrade RubyGems with less than 1GB of RAM?

[Anonymous Coward]

Is it possible to Upgrade RubyGems with less than 1GB of RAM yet? Last time I tried it with only 768MB on a server, it failed ... after churning for 5 hours.

CPAN interdependencies can be a mess ... just try to install Jiffy to see this. Then you have the different Linux distros trying to make it easier - uh, sure - with their package managers. For the initial install, those are easier, but I've gotten into .deb/CPAN hell this way. At least CPAN doesn't seem to have any minimal RAM requirements. That's a big deal for VPS hosting.

I like perl.
I like ruby.
I like about 20 other languages.

Each implementation has a purpose AND each has problems. Perl works the way I think. Ruby works the way I wish I thought. Some day, ruby won't be so slow, but Java has been promising that for 15 yrs.

Re:But CPAN is shit

[sqldr]

the documentation has improved, but the tutorial doesn't tell you everything you need to know. This is buried in the reference manual, so your first ever attempt to use puppet won't be very good.
Stuff like the inheritance model.. it's documented what it is but could provide better examples of how to use it. Eventually after figuring it out, I had a bit of a rewrite on my hands.

I've been using puppet for 2 years now and gave a talk about it at a conference. A lot of people's puppet configs overuse variables and automation stuff after not thinking the design of the system through.

We've got certain rules, like how all templates are embedded in a custom resource so you know where the variables are coming from. eg.

<%= foo %> # template

gets wrapped in:

define dotemplate($foo) { file "blah": content => template("module/blah") }

So $foo always gets passed in. If it was set elsewhere in the config, you would end up reading someone's template and not having a clue where its getting its values from.

Re:But CPAN is shit

[sqldr]

Another thing I'm doing is adding directories to make things a bit easier. I have this directory structure:

classes: class inheritance of machines
modules: reusable modules. No specific data such as IP addresses allowed in here.
roles: contains the nodes. One file per machine rather than having a massive nodes file so different sysadmins don't have SVN clashes with eachother and can work a bit more independently
glue: links classes and modules together with specific data.

So in classes I've got server.pp which is inherited by dev.pp which is inherited by dev-web.pp. This calls glue::system::setup{$hostname: env => dev} to set up resolv.conf, etc. The glue stuff also uses inheritance for location-specific stuff:

class glue::base {}
class glue::location1 inherits base {}
define glue::setup($env) { include $location }