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.
  • I was recently writing about something very similar [perl.org]. Basically, the closer you can express your program in terms of the problem domain, the more productive you become. As an example, I reduced a 14 line SQL script down to a one-line problem statement. If that one-line statement can be the program, we're doing well.

    That is what dynamic languages are coming closer to achieving. By contrast, back in the 60s and 70s, you used to have to write your JCL (Job Control Language) in such a way as to describe the record structure of the file you were opening, how much space to allocate it, how much extra space could be allocated, etc. This was in the name of "efficiency." The more work the inexpensive programmer did, the less work the expensive computer had to do. While it's not always reasonable to sacrifice computer efficiency for programmer efficiency, now that computers are cheaper than programmers, forcing the programmer to do all of the grunt work seems silly.

    • Heh. Just wait until you start programming with macros or writing subs/methods that write subs/methods. Then you're cooking with gas. ;-)

      But you'd better get crackin'. Microsoft'll have a patent on that as soon as the USPTO rubber stamps them.