🚀 go-pugleaf

Fellow MacApp castaways,
 
Merry Christmas and happy holidays!
 
Our company now has two interactive development environments in house for
evaluation;  Component Workshop, which you all have heard about, and Camelot,
which you may not yet be familiar with.
 
First, let me give some background information.  Camelot is a product of Wyvern
Technologies Inc. of Ottawa Ontario Canada.  (If you want to reach them their
phone number is 1-800-265-4368)  I am not affiliated with Wyvern in any way,
other than having stopped by their booth at Comdex.  I have used Camelot 2.7 on
the Macintosh and had a satisfying demo of it under Windows/NT.  It also runs
under Windows 3.1 and OS/2 2.0.  Suggested retail for this development
environment is $995, but introductory pricing is $749.  Applications developed
with Camelot require no runtime license.
 
Camelot is still in beta form, but should ship by January.  It is refered to as
version 2.7, but that applies more to the object model than the complete
environment, which should probably be considered a version 1.0.  The version I
saw demoed under Windows/NT appeared much more complete than the Mac version
I'm playing with, so I assume that Windows support has been the top priority.
Due to the underlying implementation of Camelot I expect that the Mac version
will be just as robust as the windows version, although right now it is a
little fragile.  Camelot and applications developed with Camelot can run on
Windows 3.1, Windows/NT, OS/2 2.0, and Mac systems 6.x and 7.x without
recompilation.
 
Now let me give you the good news/bad news (depending upon your perspective):
 
- Camelot includes an interface builder-like development environment, allowing
nearly instantaneous turnaround while prototyping interfaces.  Attaching
instance-specific methods to interface elements avoids the large number of
classes normally created to support new behaviours.
 
- Camelot has defined a new language and object model that is neither C++,
Eiffel, or SmallTalk.  It is a C-like language (called Fire) with a very
sophisticated method dispatching mechanism.  Instance specific methods are
supported, as is automatic delegation of methods from one object to another.
Multiple inheritance is not provided, but is arguably not needed thanks to
delegation.  Multi-threading tasks, asynchronous method calls and network
distributed objects are also supported.  Full support for DDE and DLL's written
in other languages (such as C) is included.  Here is an example method:
 
    #include "DCCDefinitions.D"
 
    #ifndef DCC
    #   define DCC  5
    #endif
 
    method open( arg integer ) returning string
    {
        name    string : initial value "DNX";
        element object.dcc(ne); /* object of at least class dcc in module ne */
 
        if ( arg:assigned )
        {
            name := elements[ DCC, arg ].name;
        }
        if ( name:length >= 17 )
        {
            [ New(element) ConnectionAddFirstTo( self ) ];
        }
 
        return ( name );
    }
 
Note that a preprocessor is included.  The language also includes standard flow
of control constructs and runtime feature access via the obj.<<"feature name">>
construct, where the name is any string expression.
 
- A built-in source level debugger is included which is very similar to that
available in Think C, with the additional ability to edit and run the code
without restarting your program.
 
- Garbage collection is an integral part of the environment.
 
- Camelot supports the notion of a Module (much like Component Workshop) which
eliminates name clashes when integrating independently developed code.
 
- Object repositories are used to store copies of object instances, which can
then be re-instantiated.  This implies full object persistency.  This mechanism
is used to save entire view hierarchies created in the interface builder for
later instantiation or editing.  It is also how all of the tools within the
environment are supplied, which makes the entire environment completely
customizable, from the menu bars right down to the object browsers and
inspectors.
 
- A new platform independent graphics model is supplied, along with a full
collection of standard utility and GUI classes.
 
- Methods are compiled to a byte-code form for execution on any platform.
These byte-code methods are then compiled to machine dependent code at run-time
depending upon call frequency and other criteria.  Dispatch tables are also
optimized where possible for the native platform.  A native code method
dispatch is supposed to take somewhere around four instructions.  Comparing the
performance of finished applications between Component Workshop and Camelot
will be impossible until March or later when the extruder ships for Component
Workshop.
 
There are numerous other features and aspects of the environment which I don't
have the space to discuss here.  I have been evaluating beta software on the
Mac which does not include native code generation, so I don't have any
performance figures to throw around.  The environment itself seems a little
zippier than Component Workshop and considerably more dynamic.  It is this
underlying flexibility, along with the promise of native code generation and
other optimizations aimed at efficiency, that make this multi-platform
development environment so exciting.  It also seems to deliver portability
which is still only a promise on the lips of Component Workshop and
Symantec/Apple.
 
 
Arguments against Camelot include:
 
- Its language is proprietary, and therefore a poor choice to standardize on,
while Component Workshop is based on C++, the industry standard.
 
+ Well, Component Workshop uses C++, NOT!  There is no preprocessor, and I defy
anyone to extract their source from Component Workshop (not the extruded C
files) and move to another development environment.  How will you replace the
required garbage collector?  The bottom line - they both represent a gamble of
approximately the same proportions.
 
- Relying on byte code interpretation of methods will result in a slow
application.
 
+ The native code optimization should remove any concern about this, since you
have the option to save the native code with the application.  If it is run on
another hardware platform this code is thrown away and new code is generated.
You can also restrict your application to require a specific hardware host.
 
 
Component Workshop worries me because of the unanswered questions revolving
around the extruder. (How static do the applications become?  Do we lose all
dynamic behaviour?)  I also worry about the implementation of external code
support.  Does everyone realize that you have to relink Component Workshop with
your code everytime your code changes?  And if you want internal users running
development versions of an application, do they have to run a 20 meg partition
CW session, or do we wait for an extrusion (probably a very lengthy process), a
recompile and a relink for every internal release?  My rosy glasses have just
gone a little pale.
 
Oh well, however all this works out, our plan is to keep our core application
in standard C++, supplied in a DLL or shared library, and to write the
interface in our chosen framework.  If our choice goes kerplunk down the line
we can switch to another without too much trouble.  It seems that all
development environments are headed towards a dynamic, garbage collecting,
smalltalk-like environment anyway.  My guess is that it should take about two
years to stabilize.  In the mean time, we can't wait.  An extruder in March
(?), Windows 3.1 (but not NT) in the fall, or even an alpha BedRock at WWDC is
just not enough soon enough, is it?
 
Please check out this new development option.  Let's discuss the merits and
disadvantages of the different solutions headed our way.  I'm more than willing
to share any findings, since I want to be using tools that will be supported
down the road, and that means achieving critical mass.
 
 
Sincerely,
 
Gary Bringhurst
Strata Inc.
AppleLink: STRATA3D
 
 
P.S.  I guess this did sound like a commercial for Camelot after all.  To be
fair, the 1.0 release of Component Workshop is more stable than the beta
release of Camelot, but I don't expect that to remain true once Camelot ships.