[Openmcl-devel] Using Cocoa with MCL
openmcl-devel-bounces at clozure.com
openmcl-devel-bounces at clozure.com
Sun May 11 08:57:16 UTC 2003
On Friday, May 9, 2003, at 03:56 AM, Randall Beer wrote:
> I think a prior question is What kind of Lisp interface would be
> necessary for more people to start doing serious GUI development in
> OpenMCL? There are some obvious things, but beyond these there are
> genuine design choices.
Perhaps, you want to take this even one level further up and ask more
* What is the primary objective and primary target audience ?
* Is there any secondary objective, secondary target audience ?
* What are the short term and long term goals ?
While I believe that the target audience is experienced Lisp developers,
I would nevertheless like to promote the idea that both Cocoa (and
thereby GUI) integration and an IDE are a means to invite newcomers to
play with and stay with Lisp in general and OpenMCL in particular.
Short term and long term goals should be defined taking into account
objectives, target audiences and feasibility/constraints.
> <interesting technical discussion snipped>
> What do people think? What is the minimum GUI level it would take to
> get people to, say, write a full-featured GUI editor or debugger for
> OpenMCL? What kind of a Cocoa interface would make porting CLIM to
> OpenMCL easier? Hamilton Link's inspector? Cocoa applications that
> people would like to port to or develop in Lisp?
Following the idea to appeal to both experienced Lispers and newbies,
there should be acknowledgement that there is a primare target audience,
ie experienced Lispers, *and * a secondary target audience, ie newcomers
and potential converts.
The way Cocoa is integrated into Lisp should ideally appeal to both
groups. On the one hand we might conclude that a low level interface
that looks almost like Objective-C will be appealing to Objective-C
developers because it is familiar to them, but on the other hand, if
they are to be interested in Lisp, they should be shown how using Lisp
can add value for them. If it looks just like Objective-C it won't be
obvious why they should use Lisp. It would be beneficial if they could
look at Cocoa Lisp code and say, "hey I like this", not because it looks
just the same as Objective-C but because it already hints at the power
Then, you will have people who don't like Objective-C and look at Lisp
as an alternative. To those it will certainly not appeal if it looks
just like Objective-C. Instead it will scare them away because they
sense that they will have to learn two new environments Objective-C and
Lisp. They may as well bite the bullet and learn just Objective-C. On
the other hand, a more Lisp like interface will more likely appeal to
Java and AppleScript folks who want to have a more powerful tool. For
Java folks, the fact that Lisp does GC and Obj-C doesn't will already be
a strong argument in favour of Lisp. For AppleScript folks, many Lisp
concepts will be familiar and they will instantly feel at home, but they
are used to readable syntax, so everything that looks like Objective-C
isn't going to be appealing to them.
As for other potential converts I don't really know what the appeal
would be. The most important group may be Perl folks. Although I have
led some development projects where Perl was used, none of those had
anything to do with GUIs, it was all faceless server apps, so I didn't
really get to hear any opinion in respect of GUI programming from those
folks who were on the project. Other people on the list may provide some
Of course there are many technical and feasibility constraints that will
ask for compromises being made, but I think it is a good idea to first
start with writing down what exactly the primary and secondary
objectives and target audiences are. This can then be revisited while
the project is under way. People can take a look at it when they are
stuck and ask "Why am I doing this, what am I doing this for, what am I
trying to achieve here, what's the big picture?". If the objectives and
target audiences have been set out properly it will help to maintain
consistency with the "spirit of the project" and not lose sight of the
The next thing is to think about timing. It should be clearly defined
what short term and long term goals are. This will help to make sure
that the project doesn't get abandoned because of unrealistic
expectations of contributors. Some people have short term incentives and
short term expectations to participate and contribute, others have long
term incentives and long term expectations. It is therefore beneficial
to define both short term and long term goals, so that both groups will
be able to pull into the same direction.
Sorry, I can't really contribute much to the very technical discussion
going on, which I find nevertheless very interesting and educating. My
expertise is more in the field of planning and project management.
Openmcl-devel mailing list
Openmcl-devel at clozure.com
More information about the Openmcl-devel