Re: [MacPerl] what's it look like under the hood?

[Joel Rees <joel_rees@sannet.ne.jp>]

>
>On Sat, 20 Nov 1999, Joel Rees wrote:
>
>> Okay, I am required by my job to learn Perl so I can teach it. I am 
>> considering learning it for my personal use. I want to know what 
>> advantages it has over my two favorite languages, FORTH and C.
>
>Many languages don't compete against each other directly, but have
>different areas of usefulness.  I use C/C++, and I use Perl; each has an
>area where it will produce a useful solution quickest.  It's like
>comparing boxers to track stars--they are different; it's hard to compare;
>and if you already have a bias for one, you may easily miss the positives
>of the other.
>

Assumed. 

>
>> First, would anyone dare implement Perl in Perl? 
>
>There was a talk given recently at a Perl conference from the guy writing
>Perl 6 in C++.  I believe the official answer is Perl is not primarily a
>systems programming language, but an application programming language.
>
>In Perl, as you may have already observed from the responses you've
>received, one does not need to know the details of the garbage collector
>or the algorithm used to find the best match (for the most part).  When
>writing Perl, these issues are of paramount interest.

I have to tell these guys why they don't want to use VBScrapped. I mean 
stripped. I mean. Umm. Anyway, I have to be prepared with some irrelevant 
razzle-dazzle to counter the pseudo-infromation from Micro soft.

>
>On the other hand, in a few lines of Perl you can accomplish what might
>take hundreds or thousands of lines of C code (eg, open a network
>connection, download a directory listing,  then for each file:  download,
>parse it if it's HTML, pull out certain headings and put them in a
>database).  Just writing the parser in C would be a healthy task, much
>less integrating with a database, or handling the network tasks.

What advantages does this have over a good C library (that no longer 
exists) or a good class library (that never really has yet)? I want 
specific instances (like the following).

>
>Perl has a wonderful add-on module, called CPAN, which shows you the
>latest modules available to extend Perl in any direction you choose; some
>of those other modules include the HTML parsers, network agents, and
>database interaction tools.  All you have to do is download and install
>them (also handled by CPAN), and read the docs on how to use them.
>

Now I have reason to download CPAN. Thanks. :)

>
>> This is an archaic bragging issue that turns out to have been irrelevant, 
>> but I hope to get an idea of how well Perl supports parsing complex 
>> grammars. It looks great for parsing e-mail generated by html forms, but 
>> that's pretty straightforward stuff.
>
>It sounds from the way you've worded the question that the complex
>grammars in question are already formulated for easy parsing by a
>procedural language.  If you already have lex/yacc inputs for a grammar,
>you'd be crazy to try to refigure them to fit Perl.
>
>Perl's strength is that you can specify what you are looking for, in terms
>of regular expressions, the way you think of them.  You don't have to make
>a canonical grammar.

Actually, no. But the scripts my company is (presently) using don't make 
any real use of anything I can perceive as a distinguishing feature of 
Perl. I mean I can do it with fgets(), woops, strchr() and strstr() in 
less lines of C. 

I still want a little more motivation to start reading real examples of 
Perl.

>
>If speed is of the essence, and your problem is formulated to build a
>parser in C, that route will typically yield a faster-running approach.  
>For example, there is a Perl module to read and write comma-delimited text
>files (CSV files like MS Excel and MS Access create).  It is called
>Text::CSV.  There is also a Text::CSV_XS module, which replaces the
>regular expression with a parser written in C (the Perl wraps the C
>parser).  It runs a bit faster, perhaps as much as two to three times.
>For similar reasons, other modules are written in C.
>
>Why not write the whole thing in C?  Typically because the whole project
>would take too much time to write in C, and speed of coding (project
>completion) dominated speed of code (project runtime).
>

This sounds like an argument for C (if only those libraries I mentioned 
above could be pinned down). ;-)

>
>> Second, does Perl optimize? How well? Can it reduce constant expressions?
>
>If your project is of the sort that you are comparing the object code
>generated by Perl to hand-optimized assembly, you wouldn't use Perl (or
>any interpreted language, I would imagine; I don't know Forth).
>

Nobody knows FORTH, really. The truly wonderful version of FORTH just 
exists in my head, and, judging from the parts I've read out of the 
standard, most FORTH practitioners seem to be enamored with features of 
FORTH I consider bugs. (Sigh.)

>
>> Third, does Perl have multiple internal stacks, specifically splitting 
>> the control data (return addresses) from the parameter data? (I am one of 
>> those kinds of programmers with a bad habit of walking on my return 
>> addresses in C.)
>
>Walking on your return addresses?  Are you using inline assembly?  I'm not
>sure I understand your reference in C, much less how to relate it to Perl.
>I'd say it's at least as hard to do in Perl as in C.  But for a C
>compiler, how the data is passed and returned from functions is machine
>dependent, and typically depends on a set of conventions adopted by
>compiler writers for interoperability.

It is not hard to do in C. Walking on variables ranks right up there with 
memory leaks. In every C implementation (I've ever seen) the return 
address is stored in what is effectively a local variable. Easy as pie to 
walk on it. Have you ever found yourself dropped into the low-level 
debugger and the debugger doesn't know where it is? Some program walked 
on either its return address or its frame pointer, which is right next to 
the return address. 

Perl seems to have some flavor of being influenced by FORTH, so I was 
hoping, but then it's dropped me into MacsBug a few times, and I think 
MacsBug couldn't read the stack on at least one occasion. I didn't think 
I was doing anything funny, ... .

>
>Are you writing code for an embedded processor?  Perl is not the language
>for that.  But you would find that out quickly enough by trying to
>compile Perl in such a situation.
>
>
>> Fourth, what does the Perl symbol table look like? Hash table? Is nesting 
>> achieved by naming games?
>
>The perlguts documentation might tell you something.  Nobody in the
>MacPerl group dabbles in Perl internals, except possibly Matthias
>Neeracher, and he doesn't talk too much on the list.
>

Well, I was hoping to hear from him. Steve Swantz did send me some good 
clues. I guess I'll have to motivate myself to get the Panther, too. :-( 

>
>> I admit I am being lazy by asking these questions here, instead of in the 
>> main Perl lists, or even looking in the source code myself. Just trying 
>> to save time for my family. :-)
>
>That, my friend, is _exactly_ the justification for Perl.  When a
>programming job must be completed quickly and with a minimum of effort,
>without worrying about reformulating the problem into the few ways most
>programming languages expect to find them, Perl is the tool of choice.
>The first approach you try in Perl typically works (although you might not
>hit the most optimal way).  So does the second way, and the third.  You
>often don't need to obsess on algorithms, data structures, or such, unless
>you want to or your first approach was too slow.  :)
>
>My advice is to buy the O'Reilly Camel book, Programming Perl by Larry
>Wall, Tom Christianson, and Randal Schwartz, and work through the first
>few chapters.  If you still don't see the usefulness of the language by
>Chapter 6 or 7, then you probably ought not teach it.

Which would you recommend starting with? The Camel or MacPerl? I'm sure 
I'll have to order them both at Kinokuniya, although I do remember seeing 
Larry Wall's book in Osaka once. (I don't think I'll be able to get this 
company to pay for MacPerl, unfortunately.)

>
>Programming Perl is Unix-oriented, though most of the examples should work
>just fine in MacPerl.  If you want a more Mac-oriented intro, look at the
>MacPerl book MPPE, linked at www.macperl.com.  
>
>Perl's roots are as a super-capable glue language; kind of an
>AppleScript-for-Unix on steroids, but easier to use and with more powerful
>regular expressions. 
>
>Hope this helps.
>

It does. It does. The real reason I asked here instead of one of the 
lists dedicated to the guts of Perl is that I wanted some technical sales 
talk from people who can understand why my sister can't be bothered to 
write letters in VI (or WORD, for that matter). Thanks

Joel Rees

# ===== Want to unsubscribe from this list?
# ===== Send mail with body "unsubscribe" to macperl-request@macperl.org