Many years ago, I first saw Perl and downloaded a port called "Big Perl" which was Perl 4 running in a DOS Extender environment, boasting that it could slurp up entire files because it could access large amounts of memory.

This was when CPU speeds were just barely into double digits, and "large amounts of memory" was 4 megabytes.

I recall trying to use it to simply count how many lines were in a huge CompuServe message file. Knowing what I do now, it was more code than I needed, but it was still only a line or two to simply count the lines it read.

But, it never finished. It ran so slowly that it was wholly impractical for the job. So I solved it in some other way—I don't remember how.

I didn't use Perl, and it lay forgotten in the back of my mind somewhere. Then, in the days of 33Mhz '486 machines running Windows 3.1, DPMI standard 32-bit DOS, and 8 to 16 megabytes of RAM, I met Perl again.

As I recalled in Windows Tech Journal, I had just done a few little things that should be simple but was a pain to do in C++. So I decided to find a "scripting language" as a second language, to suppliment C++. It would be good at the things C++ wasn't, and vice-versa.

There were a number of them to choose from, including both Windows-specific batch languages and portable general-purpose languages. Both Perl and Icon were finalists, along with another I can't even remember.

Interestingly enough, Perl was not ahead in terms of programming constructs. Not until Perl 5 did it surpass the others in terms of Objects, closures, modules, and whatnot. Instead, what was compelling about Perl was the documentation. Icon's bible was a bound book that needed to be bought from the publisher. Perl, on the other hand, came with documentation and there were lots of examples to find. So I learned Perl, in the early '90's.

The next interesting thing happened a couple years later. Much had changed in my life—I had moved across the country, gotten married, and worked at a new job with more room for growth. My machine at work was a nearly top-of-the-line Pentium running at 90Mhz.

So, I was using Perl to go through a hundred or so C++ source files, and based on our coding style conventions and special structured documentation comments, would generate the documentation consisting of class reference listing all the members and descriptions, neatly formatted and indexed. I wrote it in RTF and this could be read by Microsoft Word.

I still had it in my mind that Perl was slow, and thought that this task could be done slowly, perhaps overnight if need be.

I had an epiphany when my 800 line Perl program chewed threw the entire body of input in the blink of an eye. This was not slow, not at all.

Now a P90 might be 30 times faster than a 16Mhz '386, but bigger advances came from disk I/O speeds and the software handling of the I/O, I'm sure. Perl changed in my mind, so I was no longer writing "scripts" but "programs" in Perl.

Then the World Wide Web was introduced, and suddenly everyone was doing it. Many new books came out about Perl, and it became a household word. Meanwhile Perl 5 did all the things it did. So my choice, a decade ago, turned out to be inspired. I wonder what ever happened to Icon or WinBatch?

I'm hoping that Perl 6 will bring Perl to "mainstream" PC applications, including shrinkwraped software for endusers.

—John

Replies are listed 'Best First'.
Re: Meeting Perl
by mikeB (Friar) on Jul 09, 2001 at 20:21 UTC
    While I've not seen ICON in quite a while, WinBatch lives on, at least at our facility. Some of the older Windows programs around here don't lend themselves to automation via command-line interfaces, OLE, etc. For these, it seems to make more sense to use an existing, tested "key/mouse stuffer" than to create one in Perl.
      While I understand not wanting to invent working wheels, if you want to create a key/mouse stuffer then I recommend looking into Win32::GuiTest or Win32::CtrlGUI.

      I have not used them, so no specific recommendations, but I have personally found that it can be a lot easier to rewrite existing batch scripts in Perl and then add error handling logic than it is to make the original robust. YMMV. (That experience was mostly with expect scripts.)