Re: [MacPerl] We need more evangelism...

[online@mactech.com (Jeff at MacTech)]

[various posters quoted:]

>Well, first let me say that this has nothing to do directly with MacPerl,
>but with Mac OS in general.  And then let me say that apart from the fact
>that (probably) more modules on CPAN run under Windows perl than MacPerl
>(most notably DBI and Tk), I don't see how MacPerl lags behind Windows
>perl.

These modules are actually a biggie--ODBC is important for business
applications, for example, and would be enough to prevent some companies
from being able to use MacPerl. Also, the fact that all xs-based modules
need to be ported to run on the Mac, and seem to often be available for
Windows, is important. (Much of this may be due to the sheer fact of more
Win users out there doing the porting.)

Also, as is obvious once you think about it but I thought I'd point it
out, MacPerl is a perl interpreter and an IDE, and is unique in this
sense. It is sometimes difficult to keep the two separate, conceptually.
If you separate the two, then the interpreter is going to more in line
with the standard distribution than MacPerl taken as a whole. One very
trick part is the output window--is it interpreter or IDE? On other
systems, perl can just send output to the "standard" output; it doesn't
have to know where this is or manage this window (if there even is a
window--it could be a loudspeaker, or completely absent). MacPerl needs to
create this window if there is to be an output window at all; to make a
window, it needs to be an application, and basically needs to have menus
and the like to not be completely freaky. So on the Mac it is a slippery
slope from the "core" to a full-blown Mac app. Just food for thought.

>And I also don't see how this situation can ever be rectified.  You
>need a compiler to build the modules.  You can't just open up a window and
>type "make" in Mac OS, unless you have MPW or something.  I don't see how
>this will ever change under what we now know as Mac OS.

I agree. On the other hand, I don't understand the point of _ever_
distributing something for the Mac (or DOS or NT or Win95/97) without a
compiled version. (It's nice to have access to the source code, but really
only ONE person EVER need to build the darn things--I don't see the point
of putting others to the trouble, even in situations like Windows where
GCC is freely available. I assume that the point of distributing the
source and not the binaries for Unix systems is that the same sources work
for all but it would be a pain to try to support all of the various
flavors of Unix, since all will require separate binaries.)

>The _implication_ is that Mac OS is either too weird, or that we're a cult
>operating system, or that no one really wants to run Perl on a Mac.  OK,
>so those are incorrect implications, but there you are.  They are also
>valid implications.

The Mac is weird. It set out to be different, and it succeeded. 99.999% of
the time that is good--the downside is that porting Unix tools is a
non-trivial endeavour.

>I'd be interested to see a Mac "make" tool

I had heard mention that Metrowerks is considering supporting some sort of
Makefile for CW. Personally, I think it's a step backward, but people seem
to want it.

>>visibly Unix to those who want a Unix piece.  I'm not convinced that
>>GNUish tools, Perl, etc will just build.
>
>Ugh - they would have to remove the BSD-personality from the system to
>achieve that. That would be really a cruel move.

I'm not sure how obvious this is. Rhapsody (and OS X) are based on Unix,
but that doesn't mean they _are_ Unix, with a really really fancy X11
server.

They claim there is a complete Unix underneath, but some things are yet to
be determined: how does the Unix see forked files? (At Macworld the
engineer specifically said that this had not yet been determined--I
asked.) (I think we'd be a bit annoyed if using rename() in Perl trashed
our files because it only moved the data fork.) How does the Unix deal
with aliases which don't break when files are moved around? How does it
handle multiple volumes with the same name, and the concomitant necessity
of avoiding the use of full paths to specify files?

It seems that all of these things (and more) will mean that even if the
standard distribution builds and runs under Rhap., it may not behave the
way we have come to expect, or the way which is necessary for it to be a
viable tool to use on the Mac.
-- 
__________________________________________________________________________

Jeff Clites                Online Editor           http://www.MacTech.com/
online@MacTech.com         MacTech Magazine
__________________________________________________________________________

***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch