[Openmcl-devel] Mac App store: solving Lisp's last mile problem
Pascal J. Bourguignon
pjb at informatimago.com
Sat Oct 23 14:31:15 CDT 2010
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"
> 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
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
> 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
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/
More information about the Openmcl-devel