[Openmcl-devel] Using Cocoa with MCL

[openmcl-devel-bounces at clozure.com]

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 
generally

* 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 
of Lisp.

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 
insight.

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 
goal.

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.

rgds
bk


_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel