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 ]

Ovid (2709)

  (email not shown publicly)
AOL IM: ovidperl (Add Buddy, Send Message)

Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.

Journal of Ovid (2709)

Thursday September 23, 2004
01:25 PM

Perl Programmers as Angst-ridden Amateur Screenwriters

[ #21026 ]

Years ago I wanted to be a screenwriter so I did what aspiring screenwriters do. I wrote a bad screenplay. The screenplay has many flaws, but there are a few things that aren't flaws. While you can't see it in the HTML formatted version, it's worth noting that the margins are correct, the indenting is correct, superfluous stage directions do not exist except where necessary, etc. (Much of that was handled with the excellent ScriptThing software.)

Other things that weren't flawed in the script were the scenes moving the plot forward and the timing of the scenes were set up in the traditional beginning/middle/end (roughly 30, 60 and 30 pages each -- but mine's a tad short) format that Hollywood generally expects. However, when I took a screenwriting class, I was surprised at how the students were complaining strongly about this. As far as they were concerned, the strict formatting was hampering their artistic freedom. Well of course it hampers artistic freedom. Everyone knows how rigid the sonnet structure is and what miserable failures Shakespeare and Elizabeth Barrett Browning's sonnets were, right?

You see, what these aspiring writers failed to realize is that these were not arbitrary rules. Having the margins and formatting meet an exacting standard guarantees that someone reading the script can assume one minute of screentime per page. Thus, counting the pages ensures that everyone knows roughly how long the movie is. This translates to dollars!

The 30,60,30 rule is a bit subtler. Foreign films are often subsidized by government agencies or filmed on a very low budget. As a result, these movies can earn less money and still be profitable. While this does allow for great films to be produced, it also allows for some very strange things to get out there. Let's face it, The Pillow Book was a magnificent film, but it also grossed less than 3 million in the US. I don't know the budget for the film, but a gross that low in the US is frequently a financial disaster (Gigli made more than twice what "The Pillow Book" made.)

Hollywood movies are generally not subsidized by the government. Instead, they have to succeed or fail on their audience appeal. Directors such as Michael Cimino who forget that are quickly out of a job. Hollywood movies have to show a profit (well, no they don't. Oversimplification is necessary here.) That's what these aspiring screenwriters keep forgetting. Yes, they can write their art-house movies and have five people say what a great film it was, but if they want to "make it big," they probably have to bow to reality (at this point, the writers yell about how Quentin Tarantino didn't have to follow the rules, but few writers have Tarantino's ability.)

Many Perl programmers seem to have the same attitude. Frameworks? That limits my style. Certification? Why should I bow to the corporate machine? Everybody knows that MCSEs are all idiots, right? Many programmers (myself included) don't have that much of a problem with those ideas. Let's face it, when a company only hires J2EE certified programmers, they know that the programmer already has a darned good idea of how to use their framework and that rogue programmer off in the corner can't just open up a socket connection and kill the system security. Sure, the companies have to spend more on development time, but they also buy themselves some peace of mind. This isn't to argue that this is always the best course of action, but for Perl programmers to argue that it's never the best course of action is silly, yet I hear this argument all the time (hint: words like "never" and "always" frequently imply that the author of those words didn't think things through.)

Sure, we can unleash our artistic expression by creating yet another proprietary in-house enterprise-class buzzword-compliant doo-dah, but why? Now everyone who comes in has to be trained on the "meta" aspects of the system instead of being able to focus on the business rules. Frankly, I want to Perl to be seen as a viable option for enterprise class architectures. Sure, the Perl community knows it can be done, but others don't. If they even know about the widespread use of Perl at Amazon and Yahoo!, they think of this as an exception rather than the rule. Without standards -- TIMTOWTDI is often viewed as being the antithesis standards -- it's tough to hire programmers who can follow them. And sorry, but Mason, TT, mod_perl, Class::DBI and other tools are not enterprise class frameworks. If anything, they would be components of said frameworks.

You may now commence the flaming.

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.
  • Standards are good, but what part of the phrase "enterprise-class framework" means anything besides a vendor shaking his own hand vigorously?

    As far as I'm concerned, a programming language in its context with its libraries itself is a framework.

    As far as I'm concerned, "enterprise-class" means that some 500 companies in the U.S. and maybe another 1000 abroad use it deliberately and on purpose and have to customize something so general to work in their specific cases.

    As far as I'm aware, most programme

    • Quite a bit of a language's use and acceptance will be driven by those "500 companies in the U.S." Were many of them to come out and say "we're hiring Perl programmers like mad," you can bet your Camel that programmers are going to notice. Tool vendors are going to notice. A P2EE project will be born and certification processes will be created. Perl would dominate and non-Perl programmers will still continue to sneer at us while secretly hitting the books on the language in hopes of paying their mortgag

  • I'm curious. You say "TIMTOWTDI is often viewed as being the antithesis [of] standards" (I presume you meant an "of" there). Is that the case? If I write two different object models, using good Patterns for both, haven't I implemented MTOWTDI using standards -- and possibly even done it well?

    Anyway, my beef with big "do it all for you" class frameworks is that:

    1. I haven't seen any compelling evidence that it produces better results, so far

    2. it insulates me too much from the iron, and when things go
    • I must say that I agree with all of your points. However, it's a matter of perception. Until we can convince those who actually make the language decisions that Perl is a good choice, they still are going to choose other languages. Let's face it, Java's market share is due to their marketing share and despite Perl programmer's protests to the contrary, there are sometimes very good reasons to choose Java over Perl.

      For a while I thought that those reasons would go away when Perl 6 comes out but I was fi

      • I'm not sure it's possible for me to care less if the CIO of a random Fortune 500 companies doesn't realize that design patterns are a lot more important to Java than Perl because Java's much less flexible than Perl. I wouldn't expect him to make smart decisions based on that knowledge anyway.

        I don't expect big companies to make smart decisions. I expect them to make "safe", top-down decisions that don't really have much bearing on the people who do actual work. Meanwhile, I expect a big chunk of the r

        • then I'd darned well care about any company that might potentially be convinced to hire me. Big, small, stupid, smart. A paycheck is a paycheck.

          Given the choice I'm with you, I want a smaller company that tries to evaluate languages and hire the right people. Working with the right people is so much more fun than the alternative.

          But I see where Ovid is coming from as well.
  • The "subsidies" of which you speak are generally in the form of tax breaks. A great many US films also benefit from tax breaks, by the dodgy accounting the studios use to claim that films never made a profit. So I guess Hollyweird is also subsidised by the government. This same dodgy accounting is also used by the film and music industries to ensure that artists don't get their fair share of the proceeds in far too many cases.

    Peter Greenaway should be flogged with Ewan McGregor's wang for making that (and all his other) self-indulgent crapfests. But from him we do learn the valuable lesson that:

    • Yeah, I know not everyone appreciates Greenaway's work. Perhaps what puts it into perspective is realizing the Greenaway hates D.W. Griffith. D.W. Griffith was one of the pioneers of film, with the horribly racist Birth of a Nation []. What made that film interesting is that he focused heavily on telling a story in a linear fashion and its success pretty much set into stone the "Visual Novel" idea of film-making.

      Greenaway, by contrast, feels that film is primarily a visual media that should be used as suc

      • It's not just girls drooling over DiCaprio. It's also guys dooling over Kate Winslet. I plead guilty.

        But I must admit, I've never seen "Titanic" completely. Not in one go, anyway.

  • Hi Ovid!

    I'm attempting a reverse straw man attack, here. Programming should, above all else, be fun and empowering to the programmer or else you'll lose all of your good hackers (with hand waving towards Paul Graham's "Great Hackers" article).

    However, we human beings are not qualified to assess ourselves. Perl programmers fail to assess themselves accurately, but This causes problems as novices (usually more full of barely post-pubescent testosterone than knowledge) frequently and grotesquely miss the