Live data from Hacker News

Top reasons why we won't use your Perl CPAN distribution

showmetheco.de

11–13 of 13 posts

Re: Top reasons why we won't use your Perl CPAN distribution

#11
post #3

Earlier quoted context omitted.

Hm, that's interesting. Maybe it would make more sense describing the way how to choose a module from various alternatives. But what I meant by 'author should care if somebody uses it' is that he should make it usable and understandable for somebody else. If it's not, what the point of making it public and open source?

I have lots of code all over the internet "rotting". Some of it was written because I actually needed it. Some because I was learning. Some to prove a point. Some to just play. There's lots of reason to write code, and lots of reasons to let it go. Now here's the thing, putting code on the internet and typing "here it is, BSD or MIT or whatever licensed" is a trivial marginal effort. Since that effort is effectively…

A downside of this is that, for some problems, there are so many libraries to choose from that are working, documented, performant, supported, complete, etc. to varying degrees that the act of picking the best one for one's objectives is sheer impossible.

What makes this worse is that your "rotting" should be written without quotes. Most code rots incredibly fast, even if it is written to high standards. Your makefile may break, your dependencies may see an interface change, popular architectures may change (an .ini file for preferences?), etc.

Re: Top reasons why we won't use your Perl CPAN distribution

#12
post #11

Earlier quoted context omitted.

I have lots of code all over the internet "rotting". Some of it was written because I actually needed it. Some because I was learning. Some to prove a point. Some to just play. There's lots of reason to write code, and lots of reasons to let it go. Now here's the thing, putting code on the internet and typing "here it is, BSD or MIT or whatever licensed" is a trivial marginal effort. Since that effort is effectively…

A downside of this is that, for some problems, there are so many libraries to choose from that are working, documented, performant, supported, complete, etc. to varying degrees that the act of picking the best one for one's objectives is sheer impossible. What makes this worse is that your "rotting" should be written without quotes. Most code rots incredibly fast, even if it is written to high standards. Your makefil…

Meh. That is a surprisingly subjective and arguable statement, when you consider there are useful purposes for code besides running on your current dev system. For instance I frequently find code on the net that is rotten from the POV of "it runs on the latest git head of the dependencies" but completely and utterly fresh and relevant in the "how would I approach a solution in this language with this general design paradigm" POV. Other forms of "rotten" include software written to $HEAD, only to have those features never incorporated in an official release. The list goes on and the differences between "rotten" and "doesn't work for my special case" grow very indistinct.

Re: Top reasons why we won't use your Perl CPAN distribution

#13
post #11

Earlier quoted context omitted.

A downside of this is that, for some problems, there are so many libraries to choose from that are working, documented, performant, supported, complete, etc. to varying degrees that the act of picking the best one for one's objectives is sheer impossible. What makes this worse is that your "rotting" should be written without quotes. Most code rots incredibly fast, even if it is written to high standards. Your makefil…

Meh. That is a surprisingly subjective and arguable statement, when you consider there are useful purposes for code besides running on your current dev system. For instance I frequently find code on the net that is rotten from the POV of "it runs on the latest git head of the dependencies" but completely and utterly fresh and relevant in the "how would I approach a solution in this language with this general design p…

"does not run on my current system" is not a sign of rot; "I cannot even make a guess whether it will be useful for me without trying" is. To make such a guess, the following info can be helpful:

- for what platform(s) it is written (e.g. C code where tagged as 'Unix', that use Linux-isms)

- what the license is (home page claims 'free' or 'open source', source files mention license A, read me mentions license B)

- what the library does and, almost more importantly, what it's limitations are.

- what the dependencies of the library are.

- what systems the code has run on (it can for instance be useful to know that code has run in big-endian machines if your machine is big-endian)

The more of this info is present, the higher the probability that I will try to use your software.

There is lots of code out there where too little of this metadata is present. If such software is not solving some unique problem, I would prefer it if its writer did not make it available.

Post reply on HN