[Openmcl-devel] Mac App store: solving Lisp's last mile problem

[Pascal J. Bourguignon]

Alexander Repenning <ralex at cs.colorado.edu> writes:

> Seems to me that we can just keep speculating until the proverbial
> cows come home (or stay on the feedlot ;-) Slashdot has a big
> discussion on the "garden of Steven"
> http://apple.slashdot.org/story/10/10/22/1931211/
> Beware-the-Garden-of-Steven   
>
> I would like to give this whole Mac App Store development a more
> positive spin. The iPhone/iPad/IApp Store eco system has attracted
> many NEW programmers to the Apple world. A number of my ugrad students
> make a surprising amount of money from making simple games that they
> developed for iOS. An interesting observation is that NONE of these
> students actually liked Objective-C, BUT, Objective-C did the
> trick. That is, they could produce that simple app that ended up
> making some money for them.  The Mac App store may not have quite the
> same level of attraction but I think many students would still be very
> interest in making casual apps. Objective-C was not an attractive
> programming language, Objective-C is not typically a language used in
> teaching and yet this is what many students end up being interested in
> because of the integration into the more general eco system including
> the commercial aspect. To summarize, students program in Objective-C
> in-spite of not liking it, and buy Macs to develop apps in-spite of
> thinking that Macs are expensive.

Why don't they like it?

Objective-C is a mix of C and Smalltalk.  It is a much better
programming language than C++, even more so with Apple's extensions.

Nowadays, Apple's Objective-C has lambda. It's spelled ^, but it
produces closures.

While one could regret the C part of Objective-C, if you avoid it, you
can program as if you had Smalltalk.


> Now, lets speculate what could happen if the Lisp/CCL community,
> instead of debating end-of-the-world-as-we-know-it scenarios would
> embrace this eco system as well and would think, for a change, about
> what perhaps one could call the "last mile" problem of Lisp. Lets
> start with an observation of Ron Garret:
>
>     Besides, why would you even *want* to develop a retail app in CCL?
>     The leverage CCL gives you over ObjC is virtually useless in the
>     retail app world.  What makes CCL cool is that you have a
>     debugger, a compiler available at run time, the MOP,
>     macros... what would you do with those things in a retail app?
>
> I think this hits the problem really on the head. Perhaps this is
> Lisp's biggest problem. Period. Basically, we are saying that Lisp is
> great to play around, do a little debugging here and there just run
> little experiments but certainly not good enough to make a real app
> that others could actually use or even would be willing to pay for. Is
> this really true? 

Notice that InterfaceBuilder was once a Lisp program.

Lisp is great to write user interfaces.

I have a lot of problems with InterfaceBuilder, because it is a lot of
hard, manual work, to set up user interfaces with it.  Often, I just
generate them programmatically with Objective-C code.  It would be much
easier with Lisp.


> Perhaps this is true now but is there some reason
> intrinsic to Lisp why this has to stay like this?  For a lack of a
> better term I call this Lisp's Last Mile problem. I claim this is a
> great opportunity for the Lisp community in general and most certainly
> for the CCL community. Instead of contemplating syntactic
> simplifications, or whatever the CL lang newslist is currently wasting
> their time over, we could actually try to solve CL's last mile problem
> for the Mac. I realize, this probably would not be a fun
> project. Error handlers, full OS X integration etc.  requires some
> thinking. 
>
> I claim it would be very worthwhile to explore the compatibility of
> CCL with the Mac Store Apps framework. Obviously, we need to assess
> if, for instance, the use of the badly documented darwin functions
> could be a problem. I actually suspect it may not be. In the case of
> Java Apple is pulling the rug from underneath developers by declaring
> Java to be an OPTIONAL component of OS X. For a change lets use some
> positive thinking here and explore new exciting opportunities.

I agree entirely.


The use of 'undocumented' API may be justified when you want to
implement a 'close-to-the-machine' system, when you want to avoid
inefficiencies.


But if the objective is to program against a given API, this should not
be particularly hard to do, even if not as efficiently as with lower
level tricks.  It may very well mean that you'll have to have a VM
instead of compiling to native code at run-time, if the provided API
doesn't allow you to generate and jump to native code.  But that won't
prevent native code generation at compilation-time.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/