Re: [MacPerl] Prototyping Mac GUIs in MacPerl

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

online@mactech.com (Jeff at MacTech) writes:
>>From what I've seen (and I haven't worked with them extensively), using
>the Toolbox modules results in code which is almost a line-by-line
>translation of what you would do in C. So, if the goal is to prototype
>(ie, write a quick version to experiment and then a final version in C),
>you might as well just write it in C--it won't take any more code, and
>when you are done prototyping, you are _done_--you don't have to translate
>back into C, and you won't have wasted time writing the C-to-Perl adaptor
>code. And if you write it in C++ using a framework, it will be even less
>work. This is just the impresssion that I get.

I left this paragraph intact because it's a concisely and eloquently stated
position (as could be expected from a journalist :-). Naturally, I have a
different view on almost every one of these points:

 - The MacPerl direct toolbox APIs are streamlined vs. the original APIs to
   make them simpler to call and simpler to error check. The first means that
   rarely used arguments can get default values. The second means that every
   call that can fail can be error checked with the construct:

     ToolBoxCallThatCanFail(...) or die $^E;

 - Especially for visual components, the MacWindow/Pane framework (hmm, I need
   a flashier name. How about

     MacPerl
     Application
     Framework for
     Interactive
     Assembly?

   ) reduces the effort to integrate into a window considerably.
 - Turnaround time with MacPerl is much quicker than in C/C++, and I'd argue
   that for prototyping, this *does* matter.
 - It is true that you have to rewrite to get from the prototype to the final
   C/C++ version, but this can be an opportunity as well: It prevents
   management from suggesting that you ship the prototype! Prototypes don't
   necessarily make solid fundaments for production applications.
 - And, to turn the previous argument on its head, maybe soon you won't even
   need to rewrite. With a byte compiler on the MacPerl side and better Memory
   management on the MacOS side, shipping MacPerl runtimes for substantial
   applications may not be entirely unrealistic in the future.

Matthias

-- 
Matthias Neeracher   <neeri@iis.ee.ethz.ch>   http://www.iis.ee.ethz.ch/~neeri
   "A technology whose lethal products last 100'000 years is not the
    way to boil water" -- Jerry Brown

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