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 ]

lachoy (1663)


I am actually Chris Winters; I am actually living in Pittsburgh, Pennsylvania, USA; I am actually married and have three cats. (Guess what one of them is named?) I am the "OpenInteract" guy, which could be good or bad.

Journal of lachoy (1663)

Wednesday December 21, 2005
12:45 PM

"Hyperenthusiast" discussion note on perl

[ #28081 ]

While plowing through the comments on Bruce Eckel's The departure of the hyper-enthusiasts I found this piece of nonsense (not from Eckel):

Perl solved the problem of implementing a portable glue language for data processing. Then it was adapted to the initial web data processing mechanism using CGI. Its lack of scalability to build consistent and maintainable apps opened the field to newcomers like PHP.

Discussions like this are fascinating because you can see how much of themselves programmers wrap into the languages they use and the technology choices they make. It reminds me of that, "You are not your job. You are not the contents of your wallet" speech from Fight Club: You are not your language. (Right?)

Posted from; read original

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.

          • 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.
  • Great speech. "You are not special. You are not a unique and beautiful snowflake. You are the all-singing, all-dancing crap of the world. You are space... er, code monkeys."