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

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



Thanks to all of you for your thoughts!  Given that MacPerl has a future
well past the introduction of OS X,  I'd like to respond to the invaluable
Chris Nandor:

>I think that the fact that a MacPerl standalone app is
>source-readable makes it unsuited to shrinkwrapped applications anyway,
>since piracy is a no-brainer.  But for the same type of application, sure.
>While MacPerl is not ready for writing a BBEdit clone now, it may be in a
>few years.  I took "target" not as where MacPerl currently is, but where it
>is headed.  And in the future, for writing a full-fledged large
>application, I say, "why not?".

Well, let me interpret "why not" in terms of what is not now in MacPerl
that would need to be added before this could come to pass (IMVHO):

1) Distribution.  Both current alternatives of requiring a separate install
of MacPerl and the current Standalone application have problems which would
significantly reduce the attractiveness of BBEdit in MacPerl.  This really
brings us back to the original topic of this thread.  I have seen proposals
but no consensus on this point.

2) Portability.  (This is unfair, because BBEdit AFAIK is a Mac only
product, but in my domain of biomedical software, this would be an issue.)
Most of the developers in this area write for Unix, and users are split
about 50:50 between MacOS and Windows.  My very preliminary experiments
suggest to me that Python has solved this fairly well by supporting Tk on
Mac (and reportedly on Windows).    In my community, I think the ability to
write one program that would run with little or no modification under Unix,
MacOS, and Windows would be a major win.

3) Ability to run multiple programs.  This brings me to a question: the
Perl5.005-based MacPerl which will support multiple threading:  will this
allow one script to spawn multiple threads, and/or one interpreter to run
multiple scripts?  The latter is what is required to solve this problem,
and incidentally the CGI problem as well.

THANKS!

-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