swarm-support
[Top][All Lists]
Advanced

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

Re: My personal criticism


From: Marcus G. Daniels
Subject: Re: My personal criticism
Date: 06 Mar 1998 10:16:02 -0800

>>>>> "MH" == Martin Hinsch <address@hidden> writes:

MH> Wouldn`t it make sense to use for example gtk instead of tcl/tk?
MH> It`s pretty fast and already has an objective c interface. And
MH> it`s ONE library instead of four.

I don't think GTK has support for Graphs or Histograms, but I suppose
this could be implemented on top of the GTK library.  The next 
release of Swarm will have an abstract GUI interface, so folks
interested in porting to other GUIs will have a clear target.

MH> - Concerning the design of SWARM: Although it`s easy to build
MH> useful simulations in a short time using swarm, the design of the
MH> "programmer`s interface" to me seems to lack a central idea. 
MH> I think it looks somehow patchy.  Also in my opinion the whole thing
MH> is far to monolithic. 

I hope the next release of Swarm will eliminate this (it is, I believe,
mostly an illusion anyway).  The worst offender has probably been simtools
which conflagrates all sorts of things (random number library
interface, the control panel, probing widgets, etc). 

MH> - In my opinion swarm is to slow.  I really like Objective C, it's
MH> very simple and very well designed. 

MH> But on the other hand it is quite slow.

In the next release of Swarm, there will be faster dynamic method
invocation infrastructure.  At the moment, the faster code is only
used for MessageProbes, but it could also be used to generalize the
activity library's clumsy createActionTo/createActionCall methods.

And part of the perception of slowness is probably due to what you
noted before:  Tcl/Tk/BLT.  The intent of the GUI stuff is to provide a
window on a simulation, not to be fast.  It's possible to write your
application so that you can kill off those probe windows you don't
want and eliminate the GUI overhead, or just run in batch mode.

MH> So, why not use C++ or (as there, as far as I can see
MH> it, already is some really non-standard hacking included) even
MH> design an own specially suited OO approach.

We will sooner cache dynamically generated native code for
ActionGroups than rewrite the activity library in C++!  
Whatever overhead comes from Objective C method dispatch will be
irrelevant once there is a parallel Swarm kernel.

                  ==================================
   Swarm-Support is for discussion of the technical details of the day
   to day usage of Swarm.  For list administration needs (esp.
   [un]subscribing), please send a message to <address@hidden>
   with "help" in the body of the message.
                  ==================================


reply via email to

[Prev in Thread] Current Thread [Next in Thread]