I'm finding it difficult to commit to either because I lack
proper experience in both cases. Anyone would want to offer
pointers/advice?
So far my list reads as follows
o LispWors
+ better IDE
- clumsy "invoke" to ObjC land (could write a custom defmacro job?)
- clumsy string arguments for all of method, class or argument names
- No unification of ObjC heap and Lisp heap (manual ref-counting
required)
- Current status looks like "set in stone"
+ LispWorks 5.0 works on intel-Macs today though the free
personal edition is still not there
o OpenMCL
- Non existent IDE
+ Natural "Lisp-like" syntax to ObjC land
+ Uses Lisp :keywords as standin for ObjC keywords:
- No unification of ObjC heap and Lisp heap (manual ref-counting
required)
+ OpenMCL seems to want to unify Cocoa and CLOS "whatever that may
mean" in some not too distant future
- OpenMCL only works on PPC macs today. Though there seems to be
some comittement to an intel-Mac version, no date is given that
I am aware of.
This last point is not too important right now because I still
develop on a PBG4, but, I need to get some feel for the likely
future of both re the intel-Mac side.
The rationale for all this is that the whole app is Lisp for the
server side, and whatever I want for the OSX client. I've done one
too many Java Swing based app already, and I really don't fancy getting
even lower (level) to ObjC with XCode.
Many Thanks
--
JFB
On 2006-09-25 16:22:24 -0400, verec <·····@mac.com> said:
> o LispWors
> + better IDE
> - clumsy "invoke" to ObjC land (could write a custom defmacro job?)
clumsy syntax can be remedied with macros as you note
> - clumsy string arguments for all of method, class or argument names
you could construct these strings from keywords or quoted symbols if
you prefer.
> - No unification of ObjC heap and Lisp heap (manual ref-counting
> required)
This is an inherent limitation of the Objective-C runtime - it has no
real garbage collection. It's supposed to get it next year, so this
problem may be lessened simply by waiting for Leopard and deploying on
that only. Otherwise, you have to follow the standard retain/release
disciple. The Apple docs on the subject are at:
<http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/MemoryMgmt.html>
The
bottom line for lisp is that the lisp runtime cannot know how to deal
with a particular allocation because it cannot always know who "owns"
that particular object.
> - Current status looks like "set in stone"
what does this mean?
> + LispWorks 5.0 works on intel-Macs today though the free
> personal edition is still not there
This is a key feature for me - remember, the future for macs will be
increasingly intel, and increasing irrelevancy of ppc. any lisp that
isn't intel native at this point looks like a poor bet for the future.
>
> o OpenMCL
> - Non existent IDE
> + Natural "Lisp-like" syntax to ObjC land
> + Uses Lisp :keywords as standin for ObjC keywords:
> - No unification of ObjC heap and Lisp heap (manual ref-counting
> required)
> + OpenMCL seems to want to unify Cocoa and CLOS "whatever that may
> mean" in some not too distant future
this has been the plan for a couple of years now but it hasn't happened
yet (I wouldn't hold my breath)
> - OpenMCL only works on PPC macs today. Though there seems to be
> some comittement to an intel-Mac version, no date is given that
> I am aware of.
talk on the openmcl-dev list indicates that 32 bit intel machines will
*never* be supported, which makes this a non-starter if you want to
support, for example, currently shipping MacBooks, MacBook Pros, iMacs
...
LispWorks is far from perfect, but it is a supported product that
already runs on Macs - both intel and ppc, as well as Windows and
Linux. OpenMCL is, right now, a ppc-only lisp. Gary Byers is a great
guy, and very receptive and responsive to user ideas, comments and
requests, but at the end of the day he has distinctly limited time so
unless you can pay him a serious chunk of change he's going to take
OpenMCL in the directions that he thinks best at the pace allowed by
his free time to do so. Therefore, if I were you, I would subscribe to
the mailing list and/or read the archives to get a feel for where and
how quickly OpenMCL is going and see whether this will ultimately suit
your needs.
Raffael Cavallaro wrote:
> On 2006-09-25 16:22:24 -0400, verec <·····@mac.com> said:
>
> > o LispWors
> > + better IDE
> > - clumsy "invoke" to ObjC land (could write a custom defmacro job?)
>
> clumsy syntax can be remedied with macros as you note
>
> > - clumsy string arguments for all of method, class or argument names
>
> you could construct these strings from keywords or quoted symbols if
> you prefer.
>
> > - No unification of ObjC heap and Lisp heap (manual ref-counting
> > required)
>
> This is an inherent limitation of the Objective-C runtime - it has no
> real garbage collection. It's supposed to get it next year, so this
> problem may be lessened simply by waiting for Leopard and deploying on
> that only. Otherwise, you have to follow the standard retain/release
> disciple. The Apple docs on the subject are at:
>
> <http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/MemoryMgmt.html>
>
> The
>
> bottom line for lisp is that the lisp runtime cannot know how to deal
> with a particular allocation because it cannot always know who "owns"
> that particular object.
>
> > - Current status looks like "set in stone"
>
> what does this mean?
>
> > + LispWorks 5.0 works on intel-Macs today though the free
> > personal edition is still not there
>
> This is a key feature for me - remember, the future for macs will be
> increasingly intel, and increasing irrelevancy of ppc. any lisp that
> isn't intel native at this point looks like a poor bet for the future.
>
> >
> > o OpenMCL
> > - Non existent IDE
> > + Natural "Lisp-like" syntax to ObjC land
> > + Uses Lisp :keywords as standin for ObjC keywords:
> > - No unification of ObjC heap and Lisp heap (manual ref-counting
> > required)
> > + OpenMCL seems to want to unify Cocoa and CLOS "whatever that may
> > mean" in some not too distant future
>
> this has been the plan for a couple of years now but it hasn't happened
> yet (I wouldn't hold my breath)
>
> > - OpenMCL only works on PPC macs today. Though there seems to be
> > some comittement to an intel-Mac version, no date is given that
> > I am aware of.
>
> talk on the openmcl-dev list indicates that 32 bit intel machines will
> *never* be supported, which makes this a non-starter if you want to
> support, for example, currently shipping MacBooks, MacBook Pros, iMacs
> ...
>
> LispWorks is far from perfect, but it is a supported product that
> already runs on Macs - both intel and ppc, as well as Windows and
> Linux. OpenMCL is, right now, a ppc-only lisp. Gary Byers is a great
> guy, and very receptive and responsive to user ideas, comments and
> requests, but at the end of the day he has distinctly limited time so
> unless you can pay him a serious chunk of change he's going to take
> OpenMCL in the directions that he thinks best at the pace allowed by
> his free time to do so. Therefore, if I were you, I would subscribe to
> the mailing list and/or read the archives to get a feel for where and
> how quickly OpenMCL is going and see whether this will ultimately suit
> your needs.
There is a experimental openmcl-darwinx8664-snapshot-060826.tar.gz .
I don't care much about current 32bit Intel machines. Probably all
machines will be 64bit Intel (Core 2 and above) in the near future
(iMacs and MacPro are already 64bit Intel). If there is any
64bit Macbook, I'll sell my 32bit Macbook immediately.
As much as I like these Lisps, I think there is a massive opportunity
for
a (new) Lisp which has a Cocoa-based IDE and Cocoa-based libraries.
Just like MCL with the old Mac OS. The LispWorks IDE is a bit
old-fashioned
and not really Mac-like. OpenMCL's IDE is just a sketch. But OpenMCL
could
be the underlying base Lisp for such an IDE.
On 2006-09-27 16:11:28 +0100, ·······@corporate-world.lisp.de"
<······@corporate-world.lisp.de> said:
> As much as I like these Lisps, I think there is a massive opportunity
> for a (new) Lisp which has a Cocoa-based IDE and Cocoa-based libraries.
> Just like MCL with the old Mac OS. The LispWorks IDE is a bit
> old-fashioned and not really Mac-like. OpenMCL's IDE is just a sketch.
> But OpenMCL could be the underlying base Lisp for such an IDE.
I too have been considering an "OS X Like Lisp IDE" for a while, but
I'm just put off by the amount of work.
One possible route, though, could be to consider an existing
open source OSX "text editor" and adapt Slime to connect to
a regular CLI Lisp.
I have looked at Smultron, http://smultron.sourceforge.net/
as a possible starting point...
--
JFB