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.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • What's really funny is that Bruce Eckel chides Bruce Tate for the same kind of sloppy thinking that Tate used in Beyond Java.

    <devils-advocate>
    Nevertheless, Eckel has a point, however horribly he stated it. Perl does have a scalability problem with webapps, and we've known it for years. Given enough smart people, you can use any language to get anything done. (But, please, I beg you, keep me away from the APL programmers who want to reimplement Amazon.com! Or the lispers reimplementing del.icio.us
    • How do you optimize to help novices without hobbling the experienced?

      • by ziggy (25) on 2005.12.21 15:03 (#45312) Journal
        I dunno, exactly. But Rails looks like it's doing a good job. Maybe there are some lessons to take away from that...

        Step away from the web, and Python did a better job than Perl in that particular respect. Zope is nothing if not a rat's nest of expert coding. Totally befuddling in its own right, but the Zope team wasn't overly hobbled by Python's help-the-newbies approach.

        Haskell, on the other hand, goes to the opposite extreme: hobbling the novices and helping the experienced. ;-)
        • I'm starting to think people are learning the absolute wrong lessons from Rails.

          The right lesson probably starts with "Extract frameworks -- don't build them." Of course, one probably right lesson that some people could learn from Rails is that a language with expressive abstractions can be easier to program in than one without.

          • Those are certainly two important lessons to learn.

            Equally important is the Perl dictum that easy things should be easy, and hard things should be possible. Eckel's experiences with EJB and Zope highlight that big do-everything frameworks (especially when designed in advance) show are a lesson on how to optimize the simplicity out of a solution.

            Abstraction is important, but not at the expense of simplicity. C++ and Lisp are proof that powerful but befuddling abstractions don't buy much value in the large
            • Perhaps Python's problem is that perfect isn't better. I can only see it as a very reactionary language, despite a handful of nifty projects (Psyco, PyPy, py2exe, Iron Python, Jython) that make me jealous. Perhaps that's a failure of my imagination.

              Perhaps part of Ruby's success was its obscurity, in that the type of people who go looking for a language such as Ruby when it doesn't have English documentation or libraries or a large English-speaking community are the kind of people who can write really g

          • They keep saying that, but then I wonder why anyone would build such a big framework with all the helper classes and code generation if it was just for one project (i.e. Basecamp). If I was on a project and we were building that much infrastructure, I'd consider it a big mistake. I think they either planned to make Rails a framework from the start (in which case the whole "extract, don't build" thing is highly suspect) or they massively overengineered the design of Basecamp.