Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

The Many Axes of Software Development 16 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • Your list reminds me of my essay about "What Makes Software High-Quality?" [shlomifish.org]. 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 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.

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

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

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

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.