Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This blog post shows an interesting difference between the Perl community and the Ruby community. The Ruby community lives to write long blog posts about why you are writing code wrong. The Perl community just makes a library everyone can use to avoid getting things wrong in the first place.

(http://search.cpan.org/~tlbdk/Privileges-Drop-1.00/lib/Privi...)



Interesting point, but I think of it as teaching a man how to fish and giving him fish. If you read and understand this blog post,

1. You can write your own lib

2. You can spot bugs in other programs regarding privileges

3. You have an understanding of how privileges work and can transfer that knowledge to other programming languages/problems.

4. When you use a third party lib for, say dropping privileges, you can actually verify that they are doing it right because you actually understand what is going on and what is needed.


Consider the case where the blog post is not entirely correct. How do you tell everyone that cut-n-pasted the code from the blog to fix their apps?

You can't. At least with libraries, someone can report a bug or send a patch, and you can release a fixed version. Any reasonably competent developer will eventually notice the new version and upgrade the module. Problem fixed.

With a blog post, there is no reasonable way to push out new features, patches, bug fixes, security fixes, etc.


You are thinking in terms of code. I'm thinking in terms of knowledge.

What you should take away from the blog post is not the code. It is the knowledge. It has given a good starting point, on doing your own research. Just using a lib usually never leads to that.


Using a lib can get things done. Sometimes you have to get things done now and have to come back to understanding the problem in depth later.

Debugging through someone else's library is often a great way to do that. (Provided your language/environment's debugging support is good enough.)


Sometimes you have to get things done now and have to come back to understanding the problem in depth later.

This is a great way to create whole new problems.


Do you know every implementation detail of the database management system you use?

The fact that proprietary databases exist means that you can use libraries without understanding all the code in them.


You left out:

5. When the Ruby library for doing this is written and published, and you're trying to convince people to use it instead of rolling their own, you can refer them to this blog post.


Are you suggesting that the Perl community didn't follow the strategy of

a) making this mistake over and over for a decade

b) finally realizing, in the course of some blog posts or their equivalent, that they needed a library to fix it?

c) making that library?

Because here's what appears to be the Perl equivalent of this Ruby blog post, from 2005:

http://use.perl.org/comments.pl?cid=45240&sid=29890

This post is promoting the Proc::UID library, which was apparently only a year old at the time and was not quite finished. The release on CPAN was marked "for testing and review purposes only. Please do not use in production code."

http://search.cpan.org/~pjf/Proc-UID-0.04/UID.pm

The newer Privileges::Drop library, which you link to, dates back only to 2007.

Perl is more mature than Ruby. But perhaps only a few years more mature.


Yes, the author of Proc::UID discussed his module in public. That's not what I'm talking about here, I'm talking about the Ruby community's general love for cut-n-paste instead of actual library writing.

Anyway, compare planet perl and planet ruby some time. The Ruby posts are overwhelmingly "cut-n-paste this code" and the Perl posts are generally "here is a module I wrote". Different cultures.


Anecdotally, most Ruby blog posts I've seen describing how people are "doing it wrong" are just introductions to a gem or plugin on someone's Github account.

Seems to me that you're just taking a cheap shot at Rubyists. :)



The Smalltalk community did it like this:

    - Usenet posts about how to write code correctly 
      (predated blogs)
    - Smalltalk images that contained badly factored code
      written by junior people, in all the places where
      other junior people would look and imitate
    - Years after the heyday of Smalltalk, there's now an
      automated tool that will find bugs and critique code
      for you, but at this point there are very few who 
      care.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: