[Date Prev][Date Next][Thread Prev][Thread Next] [Search] [Date Index] [Thread Index]

Re: [MacPerl] Perl Shared Library (was Re: [MacPerl] ports andbuilds)



As a lurking MacPerl user, I have been watching this and related
discussions with great interest and greater perplexity.  To me, there are
two big questions that prevent me from forming a clear opinion on any of
the questions being discussed:

1) For what tasks is MacPerl primarily being targetted?

2) What will MacOS X be like; e.g. will it make MacPerl as it currently
exists irrelevant?

As to the second question, I have not a clue.

As to the first question, I have some fairly strong opinions.  As a
bioinformatics guy, I am a biologist first and a computer guy second, and
take the easy programming path wherever I can.  I tend to use Unix for any
server-type tasks, Mac for day to day productivity (e.g. I am composing
this on a Mac) and I try (boy do I try!) to find some use for Windows95.
The two languages I currently use most often are Python and Perl.  On Unix,
I use Python and Perl roughly 50:50, depending on the project.  I have both
Python and Perl installed on my Mac and on my Windows95 laptop.  On
Windows95, I have not found either of these languages to be particularly
useful; if I had no alternative, I could use them there, but I do have
alternatives.  On the Mac, I use MacPerl a lot, but Python rarely, and I
think this is important; the MacPerl app is the difference.  Although I do
a lot of my editing in BBEdit, being able to knock out a quick program in
MacPerl or to make a quick change during debugging is an overwhelming
advantage.

Also important in my opinion is what I use MacPerl for, and what I have
decided not to use MacPerl for.

1) I absolutely rely on MacPerl for lots of ad hoc text processing tasks.

2) I built one rather large package for a client in MacPerl.  It sure was
not a classic, polished Mac application, but this was a technical package
for technical users, and that was acceptable.  In this case, preinstalling
MacPerl on their hardware was no problem.  By the way, I made heavy use of
droplets and the client found that to be a very satisfactory interface for
the package.

3) I do NOT use MacPerl for CGIs.  Partly this is because I don't like the
Mac as a server (it is too unstable, in my hands) but in fact I *am*
running a website on a Mac, and, with one small exception, am not using
MacPerl CGI's.  This is because of the limitation of being able to run but
a single MacPerl thread.

4) I have not used MacPerl for GUI work.  I have played a bit with the new
toolbox stuff, and I may yet complete a GUI package using it, but frankly,
if I was going to go to that much trouble, I suspect I might just as well
do the thing in Codeworks and C.  To tell you the truth, I miss the old
Microsoft Basic for the Mac; it made GUI on a Mac quick and easy.  Again,
what you ended up with was less than a classic Mac app, but where that was
acceptable, it made it possible to knock something together very fast.

Just one users viewpoint.

-David-

David Steffen, Ph.D.
President, Biomedical Computing, Inc. <http://www.biomedcomp.com/>
Phone: (713) 610-9770 FAX: (713) 610-9769 E-mail: steffen@biomedcomp.com



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