[MacPerl Announcement] MacPerl Roadmap

[Matthias Ulrich Neeracher <neeri@iis.ee.ethz.ch>]

My innocuous reflections about performing a humanitarian act on MacPerl
have triggered a somewhat more vehement response than I expected, so now
that Apple has made their OS plans official, I'll try to clarify what I meant
with my remarks.

First of all, what is discussed here is only the question how perl will
look in the new part part of the new OS - the "yellow box" of Rhapsody.
MacOS 7 will stay around well into the next millenium, and so will the
Rhapsody "blue box" and in them MacPerl as we know it today. Furthermore,
my current Mac will probably not be upgradeable to Rhapsoy anyway.

Now, what are the Macish parts of MacPerl?

 1) A few thousand lines of compatibility code, most of it in GUSI.
 2) Roughly 20000 lines code for the MacPerl application.
 3) The toolbox interfaces, currently a bit more than 6000 lines.

The point of my earlier remark was that almost none of 1 and 2 will make
it into a yellow box perl, and they will hardly be missed at all.

1 will not be needed because perl compiles out of the box on NextStep and,
unless Apple works hard to break it, will be compilable on Rhapsody.

2 will not be needed because process creation will be much simpler in
Rhapsody. I expect there still will be droplets, but they will run the
scripts themselves instead of launching MacPerl to run them on their
behalf. The same goes for CGI scripts. Plugins for whatever editors
make it to Rhapsody will run Perl scripts directly.

So all that will remain from MacPerl will be some of the toolbox
interfaces from 3, and most of you have not yet used them, so I can
say with some certainity that hardly anything that you associate with
"MacPerl" today will make it to the Rhapsody yellow box. I'm also
fairly certain, though, that perl on the Rhapsody yellow box will be
much more powerful than MacPerl today.

For me, this means that I can drop the labor intensive task of building
core distributions and focus on the much more interesting interface modules.

I hope this clarifies what I meant with my earlier remarks regarding the
future of MacPerl.

Matthias

-----
Matthias Neeracher   <neeri@iis.ee.ethz.ch>   http://www.iis.ee.ethz.ch/~neeri
  "The current Apple developer tools organization serves to produce software,
   or at least a close facsimile thereof, evangelize developers to use said
   `software', and then make said `software' unsupported. One might consider
   this an interesting form of S&M, but there is little negotiation involved
   and its seldom consensual." -- Zalman Stern