Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

autarch (914)

  (email not shown publicly)

Journal of autarch (914)

Monday December 01, 2008
11:13 PM

The Many Axes of Software Development

[ #38000 ]

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 .

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • 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...

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

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

      • The first question of a modern is "Would you like me to configure as much as possible automatically?" And usually is able to configure everything automatically.

        Strawberry Perl comes with a preconfigured CPAN/ 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.

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

          • 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 t

  • Well put, Dave.

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

    • 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,, and HTML::Template don't work so great. They work for yo

      • 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

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

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

  • I keep getting deleted messages from you (presumably from your cross-posting software, maybe one for each reply). (If it continues, I'll "unfriend" you -- nothing personal.)
    • I killed my cross-poster, cause I couldn't figure out how to make it smart enough.