People want many things from software, and those desires are often contradictory. There's a constant back and forth about what people want from CPAN modules, in particular. It seems like we have the same arguments year after year. I think talking about priorities before talking about why something is good or bad is crucial.
So what are these priorities? How do they work together? Which ones are contradictory? Which ones are most important to you, and when do the priorities shift?
(Note: when I say library below, mentally substitute "module, library, distro, or framework")
Well-vetted - When looking for a library, you might want something other people have already used for a while. You want to know that it does what it says on the box, and that most of the big bugs have been found.
Cutting Edge - Some folks like to use new stuff. It's fun to experiment, and often the new stuff is the most advanced, most interesting, most time-saving. It could also be the biggest new piece of shit, the buggiest, slowest, etc.
Dependency free - The CPAN depdendency discussion never goes away. Some people really, really don't like large dependency chains. When you want to use a module as part of an app, and you want non Perl gurus to install that app, this becomes a huge issue. Telling them "just install these 100 modules from CPAN" doesn't cut it.
Small (does one thing) - Less code means less bugs. It also means less docs to read, and makes a library simpler to learn.
Easy to integrate - Some libraries are designed to be integrated with other modules (Catalyst), some want you to embrace their world (Jifty).
Complete - Some libraries come with a complete solution (Jifty) and some require you to put together a bunch of pieces into a whole (Catalyst).
Fast - Sometimes speed (of compilation and/or execution) really matter.
Memory frugal - Just like with speed, sometimes memory usage matters.
No XS - Sometimes you're stuck using a system where you can't compile anything. Or maybe you have a compiler, but the module requires external C libraries, and you can't install them (a hosted account).
Active development - Maybe you feel more comfortable knowing the module has a future, even if that means a higher rate of change.
Stable - On the other hand, maybe you want something that's just done, where you know new releases will be infrequent and backwards compatible.
I'm sure there are more priorities (feel free to mention some in the comments). It's easy to say we want all of these things, but there are many, many conflicts here. I won't go into all of them, but here's a few examples.
If you want well-vetted, you're not going to be using cutting edge code.
If you want dependency free, that code is probably not well-vetted. That dependency free code probably has some reinvented wheels, and those wheels are probably less round than the dependency they avoid.
If you want fast or memory frugal, you probably can't also insist on no XS. If you want complete solutions, than small and easy to integrate may go out the window.
Personally, my top priorities are usually small, easy to integrate, and active development. I'd rather learn several small pieces and put them together than try to digest a big framework all at once. And I'd rather have an active community, even if I have to keep up with API changes.
I don't care too much about fast or memory frugal. I work on a lot of webapps, which are often less demanding performance wise, at least if you can count on a dedicated server or two. Contrast this to a small "throw it in cgi-bin" app. Webapps also often have a lot of opportunities for speed improvements at the application level with caching and other strategies, so I worry less about the underlying libraries.
I'd much prefer well-vetted to dependency free. I think the latter is an entirely false economy, and what we really need are much, much better installer tools.
But these are just my priorities for the work I do most often. If I were working on an embedded data-crunching app, I'm sure my priorities would change quite a bit!
I'd like to see people state their priorities up front, and explain why it's important for the work they do. Often this gets left out of the discussion. Without this information, we often end up just talking past each other.
Cross-posted from House Absolute(ly Pointless) - permalink.
Your list reminds me of my essay about "What Makes Software High-Quality?". I should note that I didn't touch upon the trade-offs you are mentioning.
my top priorities are usually small, easy to integrate, and active development. [...] I'd rather have an active community, even if I have to keep up with API changes.
Doesn't that conflict with "small"? If a module is small, there isn't much room for development, is there? (I'm thinking of the "Tiny" modules, but maybe you have something else in mind). It seems that usually when modules are actively developed, they become less and less small...
Re:small but active
autarch on 2008-12-02T22:42:22
Small is relative to the size of the problem, and something can be way too small. I'd say DateTime is small, in that I intentionally left as much to other modules as possible (formatting, parsing, other calendars, events, etc.) But it's still got a lot of stuff in it.
Maybe instead of small I should say "focused on a few well-defined tasks".
The "better installer tools" are already there. Instead of typing
install Some::Module
just use
notest install Some::Module
or even
force notest install Some::Module
But it's another question if you still feel good after such an installation.
Re:Installer tools
autarch on 2008-12-02T22:40:14
That is not a better installer tool. Imagine that you have something you want installed by people not familiar with CPAN. They probably don't even have the CPAN shell set up.
They might want a single command that does everything right, or maybe they want a guided interactive install ("where do images go?"). CPAN just doesn't cut it for this sort of stuff.
Re:Installer tools
srezic on 2008-12-02T23:00:02
The first question of a modern CPAN.pm is "Would you like me to configure as much as possible automatically?" And usually CPAN.pm is able to configure everything automatically.
Strawberry Perl comes with a preconfigured CPAN/Config.pm. So the user does not see even this question.
And then everything the user has to do is to write
cpan Some::Module
from command line. "force" seems to be available as an command line option, "notest" does not. Maybe this needs to be added.
Re:Installer tools
autarch on 2008-12-02T23:18:19
Strawberry's version is pretty slick.
But you can't assume a modern, properly configured CPAN shell in an installer. If the first part of your install documentation says "install a modern version of CPAN.pm and make sure it's configured correctly", that just won't cut it for many use cases.
I like CPAN and think it's great for developers, but it's not really suitable for end-users of the applications we develop.
Re:Installer tools
srezic on 2008-12-03T23:22:13
Well, add the field of various installation methods and
installers as another axis to your list:-) It ranges
from "download and install everything manually", over
platform-independent installation helpers like CPAN/CPANPLUS,
platform-dependent installation helpers (apt-get, yum, ppm,
ports/packages...) to installation binaries which cover everything (PAR,
or a.msi/.exe installer). What I would like to see is a "meta packager" which would spit out
.deb, .rpm, .ppm, .msi, .dmg etc. for every platform, but doing this from a single machine.
I think there is a sweet spot if you are really to go with simple designs. In that case you find solutions that are all of well-vetted, fairly dependency free, fast and memory-frugal.
I think CGI::Application, CGI.pm, and HTML::Template would all generally fit here.
Just because a solution is simple doesn't mean it has to be a compromise or not complete. There was a day when these kind of solutions were referred to as "elegant".
Re:well said
autarch on 2008-12-03T05:29:30
I think you're missing my point. There's no one solution that meets everyone's needs.
Simple is good, but simple is relative to the person and problem. CGI::Application seems a bit too simple for my needs. OTOH, I think Jifty is too much. That doesn't mean either of those solutions is wrong for someone else. I'm sure for some people CGI::Application is just enough glue, and for others Jifty makes their life much easier.
For me, CGI::Application, CGI.pm, and HTML::Template don't work so great. They work for you. Presumably we have different priorities (including many I didn't mention explicitly).
Re:well said
markjugg on 2008-12-03T15:59:20
I think you're missing my point. There's no one solution that meets everyone's needs.
I meant to convey that I do very much agree with this point.
I just wanted to extended it to clarify that sometimes there are actually sweet spots between choosing features which seem at odds which each other.
Partly we are acknowledging that people have different underlying philosophies about what a good balance of features is, so what I consider a sweet spot may not seem like one to you.
This is an important discussion to have now because it seems like lately the Perl community has gotten away from a spirit of TIMTOWTDI to more of "One Right Way" attitude.
Re:well said
autarch on 2008-12-03T16:42:20
I don't think we'll ever abandon TIMTOWTDI 100%. However, that doesn't mean we need 20 ways to do everything either. Instead, for each conflicting set of concerns, it'd be ideal to have exactly one good solution.
For example, in many cases, Moose is (IMO) the absolute best way to do OO in Perl. It's downside is obviously the compile-time hit. If we need another OO solution that's very lightweight, I'd prefer to see just one. Ideally, that one would be Moose-compatible to some degree, like Mouse is.
Timtowtdi
zby on 2008-12-18T09:33:33
I think it is time to reexamine TIMTOWTDI. It is a complex subject - mixing the technical and the political. If we set aside the political meaning of it - I think the most effective technological course would be something that would work in phases of exploration of new ways of doing something and then concentrating on choosing just one optimal way.Re:well said
chromatic on 2009-01-09T06:03:26
This is an important discussion to have now because it seems like lately the Perl community has gotten away from a spirit of TIMTOWTDI to more of "One Right Way" attitude.
I'd like to see the Perl community adopt an attitude of "Make the default not suck for everyone".
Re:deleted messages
autarch on 2009-01-09T06:20:11
I killed my cross-poster, cause I couldn't figure out how to make it smart enough.
