Re: MCL v. ACLPC

["Don Mitchell" <dhm%proact@uunet.UU.NET>]

Subject:   RE>MCL v. ACLPC
Disclaimer: I'm under a non-disclosure with Franz wrt to some unannounced
features and products.  Plus, I am paying Franz to develop new aclpc add-ons
and to allow me to use those add-ons in my commercial software.

Franz purchased ACLPC from Procyon and, I believe, added the common-
graphics interface.  They've done no substantive work on the compiler.
The compiler is very rough.  ACLPC requires much more memory than MCL.

Due to porting difficulties and some platform differences in my code, I've 
not had an opportunity to judge execution speed differences.  

ACL provides a good high-level interface to native windows GUI widgets;
however, it's not comparable to views nor does it provide the type of control
that mcl provides with its access to traps.

ACL provides most of the CLOS MOP whereas mcl leaves a good bit out
(some intentionally for performance).

ACL's documentation is VERY poor.  Some of it is misleading.  A lot is 
difficult to find with two sections for each facility and some functions
only being documented in the introductory section.  Most of the documentation
is imprecise wrt argument types and return values.  Many of the functions
you need are not documented.  It's difficult to understand how and what
classes to specialize for interface functionality.

ACL's editor is limited to 32K characters although Windows no longer 
imposes that constraint on text-edit widgets.  ACL does not support
long filenames nor UNC naming (new discoveries in Windows).  The editor
is sluggish and awkward.

I don't believe the inspector allows you to change slot values or other
such information.  ACL does provide an inspect-object which is analogous
to describe-object and print-object.

ACL's debugger provides minimal support (inspecting objects in the
stack is about it, no restarts, no jump to function definitions).  There's
no geta-browser type class browser.  Disassembling a function provides
no useful debugging information (unlike mcl).

ACL is somewhat flakey with GPF or Dr.Watson drops occurring rather
frequently.

ACL does not let you create qualified methods before creating the primary.
This problem can be VERY vexing!

ACL is very touchy with forward referencing class names especially as types.
If you use :type slot options, then you must ensure that the given classes
are known prior to compiling the referencing classes.

ACL not only doesn't support but gets an error on dynamic-extent declarations.


ACLPC's bbs is a joke due to lack of participation by customers and
Franz.  ACLPC does not have a mailing list analog to info-mcl.

ACL's product support is generally very good (as is mcl's).

ACL is missing logical pathnames although I've converted Kantrowitz's.
It's also missing defsys although I've converted that too.

Unlike Apple, Franz is actively working on the product and not sitting on
its laurels.  It recognizes much of its weaknesses.

ACL provides backin-store on windows and seems to actively update widget
contents when their values change (no need to invalidate views).

---------------------
Donald H. Mitchell             Domain:  dhm@pro-solution.com
Proactive Solutions Inc.         UUCP:  uunet!proact!dhm   
5314 S. Yale Ave., Suite 402    Voice:  918.492.5192
Tulsa, OK  74135                  FAX:  918.492.5193