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

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.
  • What's really funny is that Bruce Eckel chides Bruce Tate for the same kind of sloppy thinking that Tate used in Beyond Java.

    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! Or the lispers reimplementing
    • How do you optimize to help novices without hobbling the experienced?

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

          • by ziggy (25) on 2005.12.22 10:34 (#45334) Journal
            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 (across the industry, that is). call/cc, operator overloading and y-combinators are great, but they don't help me add two numbers, or sprinkle logging statements for instrumenting a big system.

            Interestingly, there are a couple of anti-lesson to take away from here. Python, Perl, Tcl and Ruby are all equally capable languages for development today. Tcl loses out because it optimizes for procedural programming, and interfacing with C/C++ at the expense of a single object model, or a coherent library of extensions. Python got something very important wrong, but I don't know precisely what; the fact that there are about three frameworks for any given problem domain is a symtom that something is prematurely optimized in the Python world.

            Ruby, on the other hand, is deeply infused with XP and TDD. Perhaps the most important aspect of Ruby isn't the language design or implementation, but the community that has coalesced around it. If so, the reason why Rails was written in Ruby isn't a statement about Perl or Python, but a statement about the friendly microclimate surrounding Ruby that promotes agile development.
            • 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