Hello all,
I apologize in advance for being a totally new person at all of this.
I am reading other posts to learn about this topic, but if anyone could
take time to give me direct feedback I would really appreciate it.
I am working on my Ph.D. thesis and all my code is in Lisp. I learned
Scheme in school, so I have just been hacking based off that knoweldge.
Now I want to get into more serious development which is a whole new
world to me. I was using Roger Corman's PowerLisp but it is out of
date and a little buggy.
I need to do some multimedia processing, maybe process some quicktime
movies, and possibly create some small game-like applications. I am
looking at OpenMCL, MCL, and Lispworks. I may be able to get the
university to pay for it if necessary. Honestly, I couldn't figure out
how to install OpenMCL. I saw some nice multimedia and video support
for MCL online, but it is very old and I don't know if it is compatible
with the newer OSX versions. I downloaded the Lispworks demo and it
seems reasonable too, but I don't know the extent of its multimedia
support.
Basically I want to figure this out in the next month, or more like the
next two weeks. I am pretty ignorant about development since I am more
of an AI/theory person, so all of this stuff like Carbon vs. Cocoa etc.
is totally new to me. It's a little daunting with the learning code
but I am trying.
Any advice would be greatly appreciated.
Thanks in advance!
--Raposa
In article <························@z14g2000cwz.googlegroups.com>,
··········@excite.com wrote:
> I need to do some multimedia processing, maybe process some quicktime
> movies, and possibly create some small game-like applications. I am
> looking at OpenMCL, MCL, and Lispworks. I may be able to get the
> university to pay for it if necessary. Honestly, I couldn't figure out
> how to install OpenMCL. I saw some nice multimedia and video support
> for MCL online, but it is very old and I don't know if it is compatible
> with the newer OSX versions. I downloaded the Lispworks demo and it
> seems reasonable too, but I don't know the extent of its multimedia
> support.
See: <http://lisp.tech.coop/Which%20Common%20Lisp%20for%20Macintosh>
which I have recently updated to reflect corrections and additions by
the Mac OS X lisp using community. BTW, this page is a wiki, so others
can edit it to correct inaccuracies or to make additions.
Bottom Line as I see it:
For Cocoa GUI apps use LispWorks. This includes multimedia apps - for
example, the full version comes with a demo that opens a movie player
window that will play any .mov file selected via a standard Mac OS X
file browser in about 40 lines of code.
OpenMCL also does Cocoa, but is not quite ready for prime time yet -
maybe in the next major release. The main stumbling block as I see it is
that OpenMCL currently requires any application to be recompiled for
each minor OS rev (e.g. an app built on 10.3.7 will not launch on
10.3.8.)
For Carbon GUI apps (or Carbon apps generally) use MCL. It has the
nicest, high level, CLOSified interface to Carbon. If you have legacy
Mac OS Classic code, or have done previous work with Carbon, this would
be a good choice. If you need to do OpenGL with an ephemeral garbage
collector (to prevent pauses during OpenGL animations) then MCL is also
your best choice. For more on this, and for lots of useful OpenGL code
for MCL, contact Professor Alexander Repenning
<http://www.cs.colorado.edu/~ralex/>
If you need native threads, your only choices are LispWorks and OpenMCL.
If you need the very fastest compiled code, especially floating point,
use sbcl, cmucl, LispWorks, or, if you must use MCL or OpenMCL, use
Randall Beer's floating point compiler for MCL/OpenMCL:
<http://vorlon.cwru.edu/~beer/> (near bottom of the page)
If you need open source, use CLISP, OpenMCL, sbcl, cmucl or ABCL.
If you need native java integration use abcl (Armed Bear Common Lisp
runs on top of the jvm).
I think that summarizes most of it.
good luck with your dissertation.
Thanks for the comprehensive information. I am leaning toward
Lispworks if the university can pay for it. OpenMCL seems ok, but I
prefer a nice IDE.
I'll use the trial version for the next month and see how it works.
It's good to know about the other options for later possible work
though, especially abcl because of the java intergration possibilities.
Cheers
--Raposa
raposa wrote:
> Thanks for the comprehensive information. I am leaning toward
> Lispworks if the university can pay for it. OpenMCL seems ok, but I
> prefer a nice IDE.
>
> I'll use the trial version for the next month and see how it works.
> It's good to know about the other options for later possible work
> though, especially abcl because of the java intergration
possibilities.
>
> Cheers
> --Raposa
If you want to use a Lisp to make a research system that gradually can
be turned into a real OS X app your only choice is MCL. Look at some of
our apps like AgentSheets or DeepNavel as examples on OS X downloads.
AFAIK there are no other Lisp based (non-MCL) app featured at Apple
Download. I am talking about GUI-based apps not servers etc.
MCL has a wonderful and well integrated editor called Fred. You can
find numerous extensions to it including syntax coloring (yes: while
you type) and anticipatory symbol completion. You get good integration
to QuickTime and OpenGL. If you want to make games you can even get
interfaces to GamePads and Joysticks. Find some of these things here:
http://www.agentsheets.com/lisp/
Cocoa versus Carbon: there is no Cocoa or Carbon GUI. OS X's look and
feel is based on Aqua. If you pick Cocoa or Carbon has NOTHING to do
with that. You need to follow Apple's Human Interface Guildelines:
http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/OSXHIGuidelines.pdf
MCL has some faults but OpenMCL does not have an IDE, ACL because it's
current dependence on X11 is not a native app either, and LispWorks
seems to try hard to ignore just about every Apple OSXHI guideline.
LispWorks is a ported Window app which is good for cross platform but
terrible for native OS X apps. Before somebody want to flame me please
include a link to the Apple OS X downloads pages to a LispWorks-based
application. If you think you only want to bootstrap a Windows app on a
Mac use LispWorks. If you want to create an nice app that OS X users
would like to use use MCL. If price is the only issue left please have
your advisor talk to me.
Alex
In article <·······················@z14g2000cwz.googlegroups.com>,
"Alexander Repenning" <·····@cs.colorado.edu> wrote:
> Cocoa versus Carbon: there is no Cocoa or Carbon GUI. OS X's look and
> feel is based on Aqua.
Not so. Mac OS X's look is based on Aqua, but Carbon and Cocoa apps
definitely have different feels. One example explored at length in a
previous thread on this topic is that command clicking on Cocoa controls
does not bring that Cocoa app foreground, while command clicking on
Carbon controls *does* bring that app foreground.
Thus, Carbon and Cocoa have the same look - Aqua, but they most
definitely do not have the same feel.
> and LispWorks
> seems to try hard to ignore just about every Apple OSXHI guideline.
As I've noted before, this is the Lispworks IDE, and developers are in
no way wed to these choices, since one can load any nib file anyone can
create in Interface Builder, and call any Cocoa call (or any Objective-C
framework, for that matter), as well as define and initialize
Objective-C classes from lisp. Saying that because the LispWorks IDE is
not HIG compliant one cannot deliver HIG compliant apps is like saying
that all apps created with Xcode have to have the same UI style as Xcode
- i.e., simply not true.
> Before somebody want to flame me please
> include a link to the Apple OS X downloads pages to a LispWorks-based
> application.
This is simply a function of the ages of the two products. LWM has only
been available for a couple of years, while MCL has been in use by Mac
developers in one incarnation or other for two decades.
Since you've seen fit to dis every other Mac OS X lisp other than MCL, I
think it is only fair that we look at the negatives of MCL as well.
MCL is *not* a Mac OS X app bundle. This means that MCL, as well as apps
delivered with MCL have resource forks. Let's see what Gary Byers, one
of the core developers of MCL, the man who wrote the MCL compiler, has
to say about the use of resource forks in a Mac OS X application:
"resource forks are a deprecated feature of OSX (they've
been deprecated - to some degree - since OS 8.6 or so.) I can only
think of one (fairly obvious example of a) development system that
creates and depends on resources stored in resource forks, and can
think of many examples - including OpenMCL - of OSX programs that are
(mostly or entirely) blissfully unaware of resource forks."
Since Mac OS X contains a BSD layer, and many BSD tools and scripts are
completely unaware of the existence of resource forks, Mac OS X scripts
and tools can unwittingly strip the resource fork from an MCL based app
rendering it non-functional.
MCL does Carbon. Any way you slice it, Carbon is a framework whose sole
reason for existence is to allow legacy code to be ported to Mac OS X.
Apple clearly does not consider Carbon the future of the Mac platform.
If one needs any additional proof of this fact (other than the
aforementioned and obvious point that Carbon simply would not exist on
Mac OS X if there had been any way to avoid it) simply look at all the
recent app releases from Apple themselves: Pages, Keynote, Safari,
Xcode, Mail, iCal, etc. are all Cocoa applications. The only Carbon Apps
from Apple on Mac OS X are Carbon because they already existed on
classic Mac OS, and are thus, legacy apps - Finder and iTunes spring to
mind (iTunes started life as SoundJam sold by Cassady and Greene under
classic Mac OS).
Since Apple has a long history of letting least favored technologies
wither away and die, one would have to be more than a bit naive to
believe that Apple's internal attitude, funding, and allocation of
developer resources is equally split between these two frameworks.
Forward looking Apple developers who have any sense of Apple's history
choose Cocoa not Carbon. This being so, forward looking Apple developers
who want to use lisp, choose LispWorks, or OpenMCL, not MCL.
Raffael Cavallaro wrote:
> In article <·······················@z14g2000cwz.googlegroups.com>,
> "Alexander Repenning" <·····@cs.colorado.edu> wrote:
>
> > Cocoa versus Carbon: there is no Cocoa or Carbon GUI. OS X's look
and
> > feel is based on Aqua.
>
> Not so. Mac OS X's look is based on Aqua, but Carbon and Cocoa apps
> definitely have different feels. One example explored at length in a
> previous thread on this topic is that command clicking on Cocoa
controls
> does not bring that Cocoa app foreground, while command clicking on
> Carbon controls *does* bring that app foreground.
The are cases where the two app frameworks differ in terms of defaults.
In this particular case I am pretty sure Carbon app can be setup to not
bring up the window and a Cocoa app can be setup to bring it up. I
don't think HIG addresses this point. It's up to the developer to go
either route independent of Cocoa or carbon.
> MCL does Carbon. Any way you slice it, Carbon is a framework whose
sole
> reason for existence is to allow legacy code to be ported to Mac OS
X.
> Apple clearly does not consider Carbon the future of the Mac
platform.
> If one needs any additional proof of this fact (other than the
> aforementioned and obvious point that Carbon simply would not exist
on
> Mac OS X if there had been any way to avoid it) simply look at all
the
> recent app releases from Apple themselves: Pages, Keynote, Safari,
> Xcode, Mail, iCal, etc. are all Cocoa applications. The only Carbon
Apps
> from Apple on Mac OS X are Carbon because they already existed on
> classic Mac OS, and are thus, legacy apps - Finder and iTunes spring
to
> mind (iTunes started life as SoundJam sold by Cassady and Greene
under
> classic Mac OS).
What apple wants is not always what apple gets. If carbon goes away so
would the support of Microsoft, Adobe, Macromedia, EA, .... Apple
cannot afford that. Interesting discussion here:
http://www.answers.com/topic/carbon-computing
I don't care about Cocoa versus Carbon. I do like the idea of a Lisp
environment that has a rich set of tools and is HIG compliant. Number
of lisp implementations in this category: 0 This is a shame.
It's one thing to use Carbon/Cocoa to build an app and a slightly
different one to build a programming environment. Much of OS X
functionality is written in C and directly accessible via Carbon. Cocoa
adds Objective-C wrappers. Nice wrappers - conceptually. If you use a
Lisp programming environment calling OS functions via Cocoa in many
cases your just adding a layer of calls Lisp>Objective-C>C For some
apps that's irrelevant for other the call overhead can become a huge
problem.
> Since Apple has a long history of letting least favored technologies
> wither away and die, one would have to be more than a bit naive to
> believe that Apple's internal attitude, funding, and allocation of
> developer resources is equally split between these two frameworks.
> Forward looking Apple developers who have any sense of Apple's
history
> choose Cocoa not Carbon. This being so, forward looking Apple
developers
> who want to use lisp, choose LispWorks, or OpenMCL, not MCL.
Since much of Cocoa calls the same C code that Carbon does and since
just about ALL the large SW companies use Carbon how could Carbon go
away? AFAIK Apple is not rewriting OS X in Cocoa. Cocoa is a great
application framework wrapper. Not more, not less. It's not very
appealing to most cross platform developers because of the conceptual
overhead. As experiment: try to talk the FireFox people into Cocoa ;-)
Carbon is advancing quickly. All the new OS stuff is available. Few
people use it for legacy apps. Indeed most Carbon app would not run
anymore on OS 9. Metal window, drawers, ... it's all there because it's
written in C not Objective-C. For all i know the Cocoa code is probably
calling the Carbon code in many cases directly. Finally, there is no
need to use stuff like resources. MCL can access files even if they are
contained in packages and bundles.
Anyway, I don't want to add fuel to the carbon/cocoa wars ;-) My only
point is that there is not way for Carbon to go away. Technically Apple
would have to rewrite OS X from scratch, politically Apple would have
to alienate the largest SW producers for OS X (only excluding Apple of
course).
alex
In article <························@l41g2000cwc.googlegroups.com>,
"Alexander Repenning" <·····@cs.colorado.edu> wrote:
> Interesting discussion here:
> http://www.answers.com/topic/carbon-computing
This page is inaccurate:
" Carbon is more versatile in that it may be accessed using C, C++,
Pascal, Ada, or any other language with suitable interface headers,
whereas Cocoa exclusively uses Objective C and Java."
In fact Apple's own developer documentation details how to access the
Objective-C runtime. Languages doing so to my knowledge include Python,
Perl, Ruby, Common Lisp, Fscript, and of course, Objective-C and Java.
Carbon may not be "going away," but neither did MPW. Rather, Apple
simply put a great deal more manpower into Project Builder/Xcode. For
several years, MPW die hards insisted that MPW remained a viable, Apple
Supported development tool But this missed the point, which is that when
Apple puts a technology on the back burner, it acquires more and more
bit rot.
For example, of the new technologies announced for Tiger,
<http://developer.apple.com/macosx/tiger/>
are *any* unavailble to Cocoa? Answer: No.
Are any unavailable to Carbon? Answer, yes, Core Data, Dashboard, and
Automator. Core Data is only available via Cocoa; Dashboard plug-in
functionality only via Cocoa, and Automator is only availabe via Cocoa
and Applescript.
This is handwriting on the wall. Increasingly, new OS functionality will
be easily available via Cocoa, and difficult, or impossible to access
via Carbon. Thus, I choose Cocoa, and choosing Cocoa and Lisp means
either LispWorks or OpenMCL.
Raffael Cavallaro wrote:
> This is handwriting on the wall. Increasingly, new OS functionality
will
> be easily available via Cocoa, and difficult, or impossible to access
> via Carbon.
If there is this handwriting then the large SW companies (MS,
Macromedia, Adobe, ... ) large game companies and most of the large
cross platform open source projects (e.g., FireFox) cannot read. No
point in pushing this discussion any further.
I just wish that some company or open source project would create a
complete Lisp programming environment fully embracing OS X with a nice
compliant HIG interface. OS X is a great thing. I may grow to a
sustainable size even for a OS X only Lisp tool. Cocoa or Carbon. I
don't care. I don't want X11 hacks, I don't want GUIs rooted in VT100
full screen interfaces, I don't want to tinker with IDEs limited to
Emacs. Future Lisp programming environment builders should get inspired
by things like Xcode not VT100s.
alex
In article <························@g14g2000cwa.googlegroups.com>,
"Alexander Repenning" <·····@cs.colorado.edu> wrote:
> If there is this handwriting then the large SW companies (MS,
> Macromedia, Adobe, ... ) large game companies and most of the large
> cross platform open source projects (e.g., FireFox) cannot read.
MS, Macromedia and Adobe never thought Apple would survive, so they
simply decided to beat the Carbon horse until either it, or Mac OS X
died. In other words, for them, betting on Carbon was originally a bet
that Mac OS X (along with Apple) would not make it. They wanted to
maximize profits by selling into what they saw as a shrinking, doomed
market, with a minimum of investment. Carbon represented that minimum
investment. Now that Apple is doing just fine, thank you very much, this
cynical decision is coming back to bite them in the ass. For example, MS
can't be very happy about Safari, Pages, and Keynote, which are all apps
MS could have written themselves, if they had bothered to take the
trouble to do a Cocoa port of iE and Office.
Most of the Apple-only developers, or Apple-primarily developers have
moved to Cocoa, while large cross platform developers (such as those you
mention) have stuck with Carbon. Why? - because cross-platform
developers want to maintain a single code base, and Cocoa is a Mac-only
framework. This means that their unified code base must, of necessity,
exclude any features that are Cocoa-only, and thus, Mac only. Firefox
(ouch, is this an ugly app), and Adobe CS (gag) are quite intentionally
least common denominator, generic apps. MS Office is no beauty queen,
and iE is like a Mac OS 8 time warp in Aqua drag.
Finally, smaller Mac-only legacy developers, such as BareBones, and
Digitool, chose Carbon for the least-effort reason, lacking the
resources to do a Cocoa port.
Thus, for larger cross-platform developers, (and some smaller Mac-only
legacy developers), Carbon represents a least common denominator and/or
minimum effort framework. Not a ringing endorsement, either of Carbon,
or their opinion of Apple's future.
Now that Apple is looking healthy, and increasingly, new OS features are
not easily available from Carbon, you may well see them reevaluate this
earlier decision and start porting code to Cocoa bit by bit. A couple of
signs that this is already happing with Mac-only legacy developers are
Virex, which is now a Cocoa app, and the latest version of BBEdit,
which, though still a Carbon app, now sports a Cocoa drawer UI.
Since many Apple-only/primarily developers never thought that Apple was
doomed, they wanted to ensure that they had access to Apple's latest and
greatest with each new rev of their software, so they decided to port to
Cocoa or start new projects in Cocoa. Now that Apple is healthy, this is
looking like a very wise decision in retrospect.
Here's the kicker for our OP:
A corollary of the above is that it is a no-brainer that anyone starting
a *new* project should go with Cocoa.
>
> I just wish that some company or open source project would create a
> complete Lisp programming environment fully embracing OS X with a nice
> compliant HIG interface. OS X is a great thing. I may grow to a
> sustainable size even for a OS X only Lisp tool. Cocoa or Carbon. I
> don't care. I don't want X11 hacks, I don't want GUIs rooted in VT100
> full screen interfaces, I don't want to tinker with IDEs limited to
> Emacs. Future Lisp programming environment builders should get inspired
> by things like Xcode not VT100s.
Agreed. As it stands now, the only way this is going to come about is
through user-contributed code to LispWorks or OpenMCL. I'd rather see it
happen with OpenMCL, because I like the idea of user contributed
extensions to a proprietary implementation such as LispWorks less.
regards,
Ralph
Raffael Cavallaro wrote:
...
>
> Most of the Apple-only developers, or Apple-primarily developers have
> moved to Cocoa, while large cross platform developers (such as those
you
> mention) have stuck with Carbon. Why? - because cross-platform
> developers want to maintain a single code base, and Cocoa is a
Mac-only
> framework. This means that their unified code base must, of
necessity,
> exclude any features that are Cocoa-only, and thus, Mac only.
Not only did the big three software nasties (i.e., Microsoft,
Macromedia and Adobe) hedge their bets, with Apple being "beleaguered"
and all, but it's likely they also felt threatened by Apple's/NeXT's
cross platform software development tools (i.e., Multi Architecture
Binaries, Yellow Box, etc.).
Having to compete with "two-guys-in-a-garage" software developers using
Cocoa, such as Caffeine Software, OmniGroup, Stone Design, formerly
LightHouse, etc., must have seemed untenable to them. Rumour has it
that said nasties pressured Apple into knifing the baby, threatening to
not port their apps if Apple released Yellow Box. An urban legend, no
doubt, as Apple always said they had no business case to release Yellow
Box... (Yeah, right.)
Must be next to impossible for large software companies to adhere to
"Business 101" maxims like "Cut Your Losses", but if MS, Macromedia and
Adobe had started rewriting their apps from scratch in 1997-1998 (at
great expense, I realise), using Yellow Box for cross platform
compatibility to the PC, they would have finished porting a Cocoa
version of Office for Mac OS X a long time ago. It's been 7 years since
Rhapsody!
Hindsight is helpful, as always.
Olivier
Raffael Cavallaro wrote:
> Now that Apple is looking healthy, and increasingly, new OS features
are
> not easily available from Carbon, you may well see them reevaluate
this
> earlier decision and start porting code to Cocoa bit by bit. A couple
of
> signs that this is already happing with Mac-only legacy developers
are
> Virex, which is now a Cocoa app, and the latest version of BBEdit,
> which, though still a Carbon app, now sports a Cocoa drawer UI.
Please do not confuse people about the notion of a Cocoa GUI. There IS
NO Cocoa GUI! Carbon and Cocoa are two application frameworks wrapping
up OS X. How you application looks only depends on how many OS X
specific aqua components your are willing to employ. Please look at
Apple's Human Interface Guidelines. In their latest version of the
document
(http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/OSXHIGuidelines.pdf)
Apple even TELLs you how to do everything in Cocoa AND Carbon. Drawers,
sheets, metal look ... These have NOTHING to do with Cocoa. Not only is
Apple documenting that fact but I have personally built drawer, sheets,
metal... app in Carbon using MCL!!
I really prefer to take this discussion no further but as a result of
your posts I got emails flooding me with question how we implement
certain Cocoa looks (e.g., metal of DeepNavel). Don't spread this
misconception any further. There is NO Cocoa look, there are no Cocoa
GUI components. There are minor differences in the worst case you can
access Cocoa from Carbon and Carbon from Cocoa.
The big companies make good revenue with Apple but to keep their cross
platform development cost down they stick with C. While one *can* use
other languages, to get *most* out of Cocoa one should use Objective-C.
Not a great cross platform choice. To further minimize cost the big
companies are not using things like drawers etc. because they do not
exist on XP and would be hard to port. Again, this has nothing to do
with Carbon/Cocoa.
From: Christopher C. Stacy
Subject: Re: Help choosing Lisp for Mac OSX
Date:
Message-ID: <uu0mjh6wl.fsf@news.dtpq.com>
"Alexander Repenning" <·····@cs.colorado.edu> writes:
> The big companies make good revenue with Apple but to keep their cross
> platform development cost down they stick with C. While one *can* use
> other languages, to get *most* out of Cocoa one should use Objective-C.
> Not a great cross platform choice.
I am curious as to how using C, rather than Objective C, allows
portable GUIs to be developed. It seems to me that writing the
GUI for MacOS (using their events, primitives, and widgets) already
represents a cross-platform committment. If you build a GUI library
on top of that (and implement the same library for Windows and Unix),
you ought to be able to use that C library fairly easily from any language.
And of course, GCC, which is a popular compiler on all the platforms
provides Objective C.
So, what's the problem?
Christopher C. Stacy wrote:
> "Alexander Repenning" <·····@cs.colorado.edu> writes:
>
>
>>The big companies make good revenue with Apple but to keep their cross
>>platform development cost down they stick with C. While one *can* use
>>other languages, to get *most* out of Cocoa one should use Objective-C.
>>Not a great cross platform choice.
>
>
> I am curious as to how using C, rather than Objective C, allows
> portable GUIs to be developed. It seems to me that writing the
> GUI for MacOS (using their events, primitives, and widgets) already
> represents a cross-platform committment. If you build a GUI library
> on top of that (and implement the same library for Windows and Unix),
> you ought to be able to use that C library fairly easily from any language.
> And of course, GCC, which is a popular compiler on all the platforms
> provides Objective C.
>
> So, what's the problem?
>
Good question. I'd code a Mac GUI with Interface Builder and
Cocoa/ObjC, because it's the way to go and produces the best
looking and feeling GUIs in relatively short time (if I had to
learn how to do all that in Carbon, I'd need years to get anything
done). From the ObjC code you can then call any C functions you
want. These in turn can call any other language, and vice versa.
I don't see a problem just taking any random Unix/Windows
application, and sticking such a Mac GUI on it.
From: Christopher C. Stacy
Subject: Re: Help choosing Lisp for Mac OSX
Date:
Message-ID: <upsx7h2wy.fsf@news.dtpq.com>
Ulrich Hobelmann <···········@web.de> writes:
> Christopher C. Stacy wrote:
> > "Alexander Repenning" <·····@cs.colorado.edu> writes:
> >
> >>The big companies make good revenue with Apple but to keep their cross
> >>platform development cost down they stick with C. While one *can* use
> >>other languages, to get *most* out of Cocoa one should use Objective-C.
> >> Not a great cross platform choice.
> > I am curious as to how using C, rather than Objective C, allows
> > portable GUIs to be developed. It seems to me that writing the
> > GUI for MacOS (using their events, primitives, and widgets) already
> > represents a cross-platform committment. If you build a GUI library
> > on top of that (and implement the same library for Windows and Unix),
> > you ought to be able to use that C library fairly easily from any language.
> > And of course, GCC, which is a popular compiler on all the platforms
> > provides Objective C.
> > So, what's the problem?
> >
>
> Good question. I'd code a Mac GUI with Interface Builder and
> Cocoa/ObjC, because it's the way to go and produces the best looking
> and feeling GUIs in relatively short time (if I had to learn how to do
> all that in Carbon, I'd need years to get anything done). From the
> ObjC code you can then call any C functions you want. These in turn
> can call any other language, and vice versa. I don't see a problem
> just taking any random Unix/Windows application, and sticking such a
> Mac GUI on it.
Also, the applications themselves can just as well have
been written in Objective C.
On 2005-04-06 18:33:46 -0400, ······@news.dtpq.com (Christopher C. Stacy) said:
> I am curious as to how using C, rather than Objective C, allows
> portable GUIs to be developed. It seems to me that writing the
> GUI for MacOS (using their events, primitives, and widgets) already
> represents a cross-platform committment. If you build a GUI library
> on top of that (and implement the same library for Windows and Unix),
> you ought to be able to use that C library fairly easily from any language.
Yes, one could port the low level UI to Core Foundation, a C library
available both from Carbon (C) and Cocoa (Objective-C).
> And of course, GCC, which is a popular compiler on all the platforms
> provides Objective C.
Yes, but gnu-step isn't yet fully Cocoa compatible. As you know (I add
this for others who might be reading) Objective-C is rather like
smalltalk in that, in practice, it is more than just the language, it
is a whole class hierarchy as well. As a result, you wouldn't be able
to use the same Objective-C code cross platform, since your class
libraries would be different.
The principal advantage of using Objective-C on Mac OS X is like the
main advantage of smalltalk - the large class library. If you take away
the ability to use that in a cross-platform fashion, you might as well
just use C, especially if you already have working C apps on Windows
and/or *nix.
From: Christopher C. Stacy
Subject: Re: Help choosing Lisp for Mac OSX
Date:
Message-ID: <uis2zqgav.fsf@news.dtpq.com>
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-dot-mac.com> writes:
> > And of course, GCC, which is a popular compiler on all the platforms
> > provides Objective C.
>
> Yes, but gnu-step isn't yet fully Cocoa compatible. As you know (I add
> this for others who might be reading) Objective-C is rather like
> smalltalk in that, in practice, it is more than just the language, it
> is a whole class hierarchy as well. As a result, you wouldn't be able
> to use the same Objective-C code cross platform, since your class
> libraries would be different.
I am still not understanding why the problem is being identified
as Objective C. The GUI libraries -- in whatever language -- are
either cross-platform, or not. I assume they are, in fact, not.
You can't use MacOS GUI libraries on Windows, regardless of what
language those libraries are written in.
But Objective C is itself cross-platform.
My guess would be that the reason that multi-platform developers
want to use the older GUI framework is simply that they don't want
to write any new code, if they can get away with it. It's not a
matter of Objective C versus C. It's a matter of existing code
versus writing new code.
> The principal advantage of using Objective-C on Mac OS X is like the
> main advantage of smalltalk - the large class library. If you take
> away the ability to use that in a cross-platform fashion, you might as
> well just use C, especially if you already have working C apps on
> Windows and/or *nix.
I didn't follow what you're trying to say there, either.
On 2005-04-07 01:58:17 -0400, ······@news.dtpq.com (Christopher C. Stacy) said:
> It's a matter of existing code
> versus writing new code.
>
>> The principal advantage of using Objective-C on Mac OS X is like the
>> main advantage of smalltalk - the large class library. If you take
>> away the ability to use that in a cross-platform fashion, you might as
>> well just use C, especially if you already have working C apps on
>> Windows and/or *nix.
>
> I didn't follow what you're trying to say there, either.
They are two ways of saying the same thing. To use Objective-C as it is
meant to be used, one's existing code should be refactored to use the
Objective-C class library. Remember, Cocoa is much more than just a GUI
framework. It is a complete application framework, with everything from
networking and IPC to dynamic loading of other frameworks in it. If all
one is going to do is use one's existing C code base *as is* and make
very low level GUI calls using Objective-C then one might as well just
stick with C since these very low level GUI calls can be made just as
well from C.
At the very lowest level, called Core Services, both the C framework
(Carbon) and the Objective-C framework (Cocoa) are *exactly* the same -
literally. Both C and Objective-C access the same Core Services
framework (derived from Next's Objective-C Foundation framework, but
re-written in C). If this is the only level one is going to use
Objective-C at, one might as well just use C.
From: Christopher C. Stacy
Subject: Re: Help choosing Lisp for Mac OSX
Date:
Message-ID: <uacoatm2d.fsf@news.dtpq.com>
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-dot-mac.com> writes:
> On 2005-04-07 01:58:17 -0400, ······@news.dtpq.com (Christopher C. Stacy) said:
>
>
> > It's a matter of existing code
> > versus writing new code.
> >
> >> The principal advantage of using Objective-C on Mac OS X is like the
> >> main advantage of smalltalk - the large class library. If you take
> >> away the ability to use that in a cross-platform fashion, you might as
> >> well just use C, especially if you already have working C apps on
> >> Windows and/or *nix.
> > I didn't follow what you're trying to say there, either.
>
> They are two ways of saying the same thing. To use Objective-C as it
> is meant to be used, one's existing code should be refactored to use
> the Objective-C class library.
So how does this relate to running the program on Windows?
In article <·············@news.dtpq.com>,
······@news.dtpq.com (Christopher C. Stacy) wrote:
> So how does this relate to running the program on Windows?
I think the key concept here is that Objective-C is not just a language.
It loses all of its power and ease of use if you divorce it from its
class library. Since that Apple class library, known as Cocoa, doesn't
exist on Windows, Objective-C is not an attractive choice for
cross-platform development. To port a Cocoa app to Windows using
Objective-C you'd have to re-write every bit of Cocoa application
framework functionality that you used on the Mac in order to get a
version of Cocoa that used the low level Windows APIs instead of the low
level Mac APIs.
Apple actually had such a Windows version of Cocoa. It was called Yellow
Box, and Apple killed it (see Olivier Drolet's post for one speculation
as to why). Another possibility is that it would have constituted giving
away the family jewels to Windows - that is, much that made the Mac OS X
Cocoa look and feel distinctive would have been available for Windows
too. Apple doesn't want to make it easy to port *all* of a Mac OS X
app's look and feel to Windows because if all of Mac OS X's look and
feel distinctiveness were available for Windows too, why would anyone
buy a Mac instead?
BTW, since Objective-C is modeled on Smalltalk, if I wanted to port a
Cocoa application to Windows I would probably use Smalltalk on Windows
since both Cocoa and Smalltalk use message passing OO, single
inheritance, and the MVC paradigm. If you carefully wrote your Cocoa app
to keep model(s), view(s) and controller(s) separate, you could port
each piece to its Smalltalk equivalent much more easily.
From: Christopher C. Stacy
Subject: Re: Help choosing Lisp for Mac OSX
Date:
Message-ID: <umzsai7u4.fsf@news.dtpq.com>
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-dot-mac.com> writes:
> In article <·············@news.dtpq.com>,
> ······@news.dtpq.com (Christopher C. Stacy) wrote:
>
> > So how does this relate to running the program on Windows?
>
> I think the key concept here is that Objective-C is not just a language.
> It loses all of its power and ease of use if you divorce it from its
> class library. Since that Apple class library, known as Cocoa, doesn't
> exist on Windows, Objective-C is not an attractive choice for
> cross-platform development.
The argument was put forward that developers do not want
to move to Cocoa because of cross-platform portability concerns,
and Objective C was cited as the culprit.
Are you implying here that the C language libraries for
Apple Carbon are available on Windows?
On 2005-04-07 17:40:35 -0400, ······@news.dtpq.com (Christopher C. Stacy) said:
> Are you implying here that the C language libraries for
> Apple Carbon are available on Windows?
I'm saying that Carbon is a much lower level framework than Cocoa, so
the low level portions of an existing Windows app can be swapped out
for the equivalent low level Carbon calls without changing languages.
But swapping out the low level portions of this same Windows app for
low level Cocoa calls would more or less entirely defeat the purpose of
the Cocoa framework, which is the benefits of a large class library
that has been elaborated at a significantly higher level of abstraction
than both Core Services and Carbon.
If you keep most of your Windows code instead of rewriting from
scratch, you'll be using *exactly* the same low level library whether
you use Carbon or Cocoa (i.e., Core Services). So why switch to
Objective-C? You'll gain *none* of the advantages of Objective-C, and
all of the dislocation that comes from switching to a new language.
Remember, we're talking about real developers, with real existing
Windows apps. How many of these have existing apps in Objective-C? Not
many. Most have existing apps in C and C++. Cross platform developers
prefer to reuse as much of their existing Windows code as possible, not
rewrite from scratch when porting. But the only way to take advantage
of Cocoa's class library would be to rewrite your existing Windows app
from scratch. This is not an attractive proposition to Windows
developers, so rather than rewrite everything in Objective-C in order
to use Cocoa, they rewrite only the low level parts using C and Carbon.
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-dot-mac.com> writes:
> In article <·············@news.dtpq.com>,
> ······@news.dtpq.com (Christopher C. Stacy) wrote:
>
> > So how does this relate to running the program on Windows?
>
> I think the key concept here is that Objective-C is not just a language.
> It loses all of its power and ease of use if you divorce it from its
> class library. Since that Apple class library, known as Cocoa, doesn't
> exist on Windows, Objective-C is not an attractive choice for
> cross-platform development.
It's twice a lie.
- Openstep/NT still runs on MS-Windows. Granted, Apple doesn't sell
it, but it might be bought second hand.
- GNUstep runs on MS-Windows.
In both case, you get the OpenStep class library, and with GNUstep
even with some of the Cocoa API.
If you want portability you'd better stick with a portable API such as
OpenStep instead of using all the incompatible extensions added by
Apple to get Cocoa.
> [...]
> Apple actually had such a Windows version of Cocoa. It was called Yellow
> Box, and Apple killed it (see Olivier Drolet's post for one speculation
> as to why). Another possibility is that it would have constituted giving
> away the family jewels to Windows - that is, much that made the Mac OS X
> Cocoa look and feel distinctive would have been available for Windows
> too. Apple doesn't want to make it easy to port *all* of a Mac OS X
> app's look and feel to Windows because if all of Mac OS X's look and
> feel distinctiveness were available for Windows too, why would anyone
> buy a Mac instead?
>
> BTW, since Objective-C is modeled on Smalltalk, if I wanted to port a
> Cocoa application to Windows I would probably use Smalltalk on Windows
> since both Cocoa and Smalltalk use message passing OO, single
> inheritance, and the MVC paradigm. If you carefully wrote your Cocoa app
> to keep model(s), view(s) and controller(s) separate, you could port
> each piece to its Smalltalk equivalent much more easily.
IMO, it would be easier to use GNUstep...
--
__Pascal Bourguignon__ http://www.informatimago.com/
I need a new toy.
Tail of black dog keeps good time.
Pounce! Good dog! Good dog!
On 2005-04-07 17:30:30 -0400, Pascal Bourguignon <····@mouse-potato.com> said:
> It's twice a lie.
>
> - Openstep/NT still runs on MS-Windows. Granted, Apple doesn't sell
> it, but it might be bought second hand.
So you think someone should base a project on a discontinued product?
> - GNUstep runs on MS-Windows.
>
> In both case, you get the OpenStep class library, and with GNUstep
> even with some of the Cocoa API.
GNUstep is not compatibile with Cocoa, as you yourself admit below:
> If you want portability you'd better stick with a portable API such as
> OpenStep instead of using all the incompatible extensions added by
> Apple to get Cocoa.
The whole point of using Cocoa is to get all the incompatible
extensions. Both of your "solutions" don't work if you want your Mac
app to be a real Cocoa app, not some generic, least common denominator
abortion.
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-dot-mac.com> writes:
> On 2005-04-07 17:30:30 -0400, Pascal Bourguignon <····@mouse-potato.com> said:
>
> > It's twice a lie.
> > - Openstep/NT still runs on MS-Windows. Granted, Apple doesn't sell
> > it, but it might be bought second hand.
>
>
> So you think someone should base a project on a discontinued product?
>
>
> > - GNUstep runs on MS-Windows.
> > In both case, you get the OpenStep class library, and with GNUstep
> > even with some of the Cocoa API.
>
> GNUstep is not compatibile with Cocoa, as you yourself admit below:
>
> > If you want portability you'd better stick with a portable API such as
> > OpenStep instead of using all the incompatible extensions added by
> > Apple to get Cocoa.
>
> The whole point of using Cocoa is to get all the incompatible
> extensions. Both of your "solutions" don't work if you want your Mac
> app to be a real Cocoa app, not some generic, least common denominator
> abortion.
You'll never ever be able to use 100% of the API provided on a
specific system portably. If you want your application to be
portable, you'll have to restrict yourself to the portable subset of
features. OpenStep is this portable subset. POSIX is another example.
Of course, both Apple and Sun made extensions to OpenStep to try to
lock you in their products, what can you expect from commercial vendors?
At least, GNUstep tries to be helpful and implement some of the Cocoa
extensions in addition to the OpenStep compatibility base.
--
__Pascal Bourguignon__ http://www.informatimago.com/
In deep sleep hear sound,
Cat vomit hairball somewhere.
Will find in morning.
On 2005-04-07 23:00:21 -0400, Pascal Bourguignon <····@mouse-potato.com> said:
> You'll never ever be able to use 100% of the API provided on a
> specific system portably. If you want your application to be
> portable, you'll have to restrict yourself to the portable subset of
> features.
A different approach is to recognize which platform represents (more or
less) a superset of the others in terms of usability features, and code
to that. Then you can remove features for the other platforms which
don't have them.
I think this is why Windows ports to Mac OS and Mac OS X often look so
bad - Mac users are used to features that Windows developers often
don't even realize exist. Coding to the LCD subset is a good recipe for
having your app rejected by Mac users as an ugly port.
The Mac platform has always been about making things easier for users,
even if this made things harder for developers. Seeking a cross
platform subset is about making things easier for developers at the
expense of users. Mac users may not be able to articulate it this way,
but they'll notice that your app is missing usability features they've
come to expect from Mac OS X apps.
In article <·············@news.dtpq.com>,
Christopher C. Stacy <······@news.dtpq.com> wrote:
> > The principal advantage of using Objective-C on Mac OS X is like the
> > main advantage of smalltalk - the large class library. If you take
> > away the ability to use that in a cross-platform fashion, you might as
> > well just use C, especially if you already have working C apps on
> > Windows and/or *nix.
>
> I didn't follow what you're trying to say there, either.
He's saying that to use Objective-C efficiently you want things like
NSString and NSMutableDictionary, which aren't a part of Objective-C
itself per se. (You'd need GNUstep to get an implementation of these.)
These are the Foundation classes, which have nothing to do with GUIs:
http://developer.apple.com/documentation/Cocoa/Reference/Foundation/ObjC_classic
-bcd
--
*** Brian Downing <bdowning at lavos dot net>
From: Christopher C. Stacy
Subject: Re: Help choosing Lisp for Mac OSX
Date:
Message-ID: <u64yytlzv.fsf@news.dtpq.com>
Brian Downing <·············@lavos.net> writes:
> In article <·············@news.dtpq.com>,
> Christopher C. Stacy <······@news.dtpq.com> wrote:
> > > The principal advantage of using Objective-C on Mac OS X is like the
> > > main advantage of smalltalk - the large class library. If you take
> > > away the ability to use that in a cross-platform fashion, you might as
> > > well just use C, especially if you already have working C apps on
> > > Windows and/or *nix.
> >
> > I didn't follow what you're trying to say there, either.
>
> He's saying that to use Objective-C efficiently you want things like
> NSString and NSMutableDictionary, which aren't a part of Objective-C
> itself per se. (You'd need GNUstep to get an implementation of these.)
>
> These are the Foundation classes, which have nothing to do with GUIs:
I still don't see how this makes your code less or more portable to Windows.
It seems to me that if you are writing a Macintosh GUI, it's not going to
run on Windows, regardless of what lanuage you wrote it in.
On 2005-04-06 15:10:15 -0400, "Alexander Repenning"
<·····@cs.colorado.edu> said:
> Apple even TELLs you how to do everything in Cocoa AND Carbon. Drawers,
> sheets, metal look ... These have NOTHING to do with Cocoa. Not only is
> Apple documenting that fact but I have personally built drawer, sheets,
> metal... app in Carbon using MCL!!
Realize that drawers were Cocoa-only at first. This is why both Mac OS
X users, and Mac OS X developers think of drawers as a Cocoa UI feature
- because they were originally available just in Cocoa apps. Only later
(beginning with Jaguar) did Apple make drawers available via Carbon.
This is exactly what I have been saying - Apple's support for Carbon is
an afterthought. The fact that now they are available via Carbon hardly
means that the two frameworks are on equal footing.
Now, in Tiger, Apple is giving developers Core Data, and the ability to
write plug-ins for Dashboard. Core Data gives developers undo and
persistence (in multiple file flavors) essentially for free (as well as
graphical application data modeling if you want). Dashboard plug-ins
give developers the ability to add any AppKit functionality (and hence
essentially any Mac OS X functionality) to Dashboard widgets via
javascript, the language that Dashboard widgets are written in.
Again, at first, neither of these new technologies are available to
Carbon developers (unless they want to take the cumbersome step of
wrapping each and every relevant Cocoa call in a C-callable wrapper
function.) Will they eventually be directly available to Carbon
developers? Maybe. But by then Mac OS X will have moved on to the next
new thing.
So we have a situation where Carbon developers are putting drawers
into their UIs a couple of years after Cocoa developers did so.
Meanwhile, Cocoa developers are starting to use Core Data, while Carbon
developers will have to wait. This pattern is no accident. It is what
happens when a legacy technology (Carbon) gets less emphasis, less
manpower, and less support - it plays catch-up.
Rather than play catch-up I think it is wiser to use the framework that
Apple clearly wants to have all the newest technologies. That framework
is Cocoa, not Carbon.
This thread has prompted me to ask in comp.sys.mac.programmer.misc if
Carbon is a depricated API:
http://groups-beta.google.com/group/comp.sys.mac.programmer.misc/browse_thread/thread/570ad472e1ca023c/0a10eb71b9d2145a#0a10eb71b9d2145a
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
On 2005-04-07 05:42:57 -0400, David Steuber <·····@david-steuber.com> said:
> This thread has prompted me to ask in comp.sys.mac.programmer.misc if
> Carbon is a depricated API:
Not officially, no. But as many of your responses in
comp.sys.mac.programmer.misc indicated, doing *new* development in
Cocoa is not the "sane" thing to do (quoted from one of your responses).
Apple has a long history of reducing support for technologies, or
simply discontinuing them. They don't always become officially
deprecated first. One has to learn to read the signs. The most obvious
sign is where the new technologies are aimed. Look at the new
technologies coming in Tiger:
<http://developer.apple.com/macosx/tiger/>
Apple has made sure that all of these new technologies are easily and
directly accessible using Cocoa. By contrast, several of the most
innovative of them (Core Data, Dashboard plug-ins, Core Image) are
impossible to access from Carbon (unless one goes through Cocoa, a
cumbersome process of wrapping every single relevant Cocoa call
yourself in an Objective-C source file).
If Cocoa and Carbon really were on an equal footing, wouldn't these new
technologies be equally accessible from both frameworks? Apple is
making Carbon developers do a great deal of extra work to use these new
technologies because Apple has decided that Apple's manpower is better
allocated making Cocoa development easy rather than making Carbon
development easy. What does this tell you about Apple's view of the
relative importance of the two frameworks going forward? History has
taught us the hard lesson that a technology getting short shrift from
Apple is not a technology one wants to wed oneself to for future
development.
You're using OpenMCL. There's are reasons why Gary Byers, the principal
developer of OpenMCL, chose Cocoa not Carbon. You might want to take a
cue from that.
On 2005-04-07 11:38:16 -0400, Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-dot-mac.com> said:
> Not officially, no. But as many of your responses in
> comp.sys.mac.programmer.misc indicated, doing *new* development in
> Cocoa is not the "sane" thing to do
^^^^^^^^^^^
Sorry just realized my typo here - that should be:
doing *new* development in Carbon is not the "sane" thing to do
^^^^^^^^^^
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-dot-mac.com> writes:
> You're using OpenMCL. There's are reasons why Gary Byers, the
> principal developer of OpenMCL, chose Cocoa not Carbon. You might want
> to take a cue from that.
Yes, I have been doing a bit of soul searching over that. I've even
questioned my sanity, but that has a bit of an attitude.
The experimental nature (and point release incompatibility) of
OpenMCL's Cocoa bridge is, I think, the primary reason I elected to
experiment with Carbon. I'm thinking I should probably keep my
options open and play with Cocoa a bit.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
Hi Alex,
Alexander Repenning wrote:
LispWorks
> seems to try hard to ignore just about every Apple OSXHI guideline.
> LispWorks is a ported Window app which is good for cross platform but
> terrible for native OS X apps. Before somebody want to flame me please
> include a link to the Apple OS X downloads pages to a LispWorks-based
> application. If you think you only want to bootstrap a Windows app on a
> Mac use LispWorks. If you want to create an nice app that OS X users
> would like to use use MCL. If price is the only issue left please have
> your advisor talk to me.
I'm not interested in flaming you or getting into a religous discussion
on this, but I think your statement is fairly misleading. It is true
that the LispWorks IDE violates many Mac HI guidelines. But there is
nothing there to prevent you from creating a very nice Mac HIG-compliant
application. LispWorks provides a decent collection of interfaces to
standard Cocoa controls. And it has Objective-C and a foreign function
interfaces so you can get to anything you want in Cocoa or Carbon.
> If you want to use a Lisp to make a research system that gradually can
> be turned into a real OS X app your only choice is MCL. Look at some of
> our apps like AgentSheets or DeepNavel as examples on OS X downloads.
> AFAIK there are no other Lisp based (non-MCL) app featured at Apple
> Download. I am talking about GUI-based apps not servers etc.
I just submitted mine :). Thanks for letting me know about it.
John DeSoi, Ph.D.
http://pgedit.com/
Power Tools for PostgreSQL
From: Tord Kallqvist Romstad
Subject: Re: Help choosing Lisp for Mac OSX
Date:
Message-ID: <gqk8y3y21mh.fsf@aload.uio.no>
"Alexander Repenning" <·····@cs.colorado.edu> writes:
> MCL has some faults but OpenMCL does not have an IDE,
Actually it does, if you download the latest bleeding edge version
from CVS. The IDE is probably not quite ready for serious use yet
(which is probably the reason it is not included in OpenMCL 0.14.3),
but it seems to be improving rapidly.
I used to love MCL, and in fact MCL was the main reason I bought my
first Mac some time around 1997/1998. These days, I hardly ever use
it any more. OpenMCL is vastly preferable for my needs. The main
reasons are the better Unix integration, native threads, the more
active developer community, the updated documentation, and the ability
to easily create conforming GUI apps.
The documentation is probably the most serious issue -- it hasn't been
updated for almost a decade, and looks like it was written for Mac OS
7 or some similarly ancient version. As your software proves, it is
definitely possible to use MCL to create modern OS X GUI applications,
but figuring out how to do this is by no means easy. I have no idea
how to run Unix console utilities as sub-processes, how to use the FFI
with GCC, how to get proportional scroll bars, how to load NIB files,
and a lot of other common operations.
> ACL because it's current dependence on X11 is not a native app
> either, and LispWorks seems to try hard to ignore just about every
> Apple OSXHI guideline.
With the default settings, MCL is also not so great in this respect.
The organization of the menus is very non-standard, all MCL windows
jump to the front when you click on one of them, the preferences
dialog box looks very OS9ish (if not even older), the scrollbars are
non-proportional, and there is no live scrolling or live resize.
> If you want to create an nice app that OS X users would like to use
> use MCL.
In practise, I think most users would find this a lot easier to do in
OpenMCL or LispWorks than in MCL. Perhaps it would have been
different if the MCL documentation were updated.
--
Tord Romstad
Thank you everyone for the input. I downloaded the trial versions of
both Lispworks and MCL and will experiment for a month with them.
The wiki-based comprehensive answer to the question is a good idea.
In response to Ulrich's comment, I did search the web first and come
here second. I tried to ask my question politely because I was sure
that in some form or another it had been asked before. I asked again
for two reasons. 1) I am specifically interested in multimedia
applications with low overhead to get started -- I thought I might get
specific suggestions regarding this, which to some degree I have. 2)
Looking at the MCL webpage, and in the course of my search I found some
code samples designed for multimedia, such as:
http://xenia.media.mit.edu/~mt/lisp/mclhacks.html
But a lot of what I found for MCL was for pre-OSX macs and I wasn't
sure if there was similar support for OSX.
3) I am using this to create some demos to implement a "proof of
concept" for my research, at this point I am not creating full-fledged
applications (possible in the future, but not my immediate goal). I am
more theory oriented in computer science than development oriented, so
the trade-offs of Carbon vs. Cocoa and some of the specific development
features are new to me, though I am also reading up on all of this. So
I thought that by posting the question I could also get advice for a
novice that can help get me started and mention some trade-offs in a
manner different than I found when doing a web search.
I hope my motivation is less puzzling now. I really appreciate all of
the feedback I have been getting, disagreements and all.
--Raposa
raposa wrote:
> In response to Ulrich's comment, I did search the web first and come
> here second. I tried to ask my question politely because I was sure
> that in some form or another it had been asked before.
Sorry if that sounded harsh. I was just wondering why this
question is relatively common. Maybe the mentioned info-page on
lisp/mac isn't ranked high enough on Google.
> But a lot of what I found for MCL was for pre-OSX macs and I wasn't
> sure if there was similar support for OSX.
Yes, not all websites writing about the Mac have noticed that OS X
is already here (and not all software companies). ;)
raposa wrote:
> Thanks for the comprehensive information. I am leaning toward
> Lispworks if the university can pay for it. OpenMCL seems ok, but I
> prefer a nice IDE.
>
> I'll use the trial version for the next month and see how it works.
> It's good to know about the other options for later possible work
> though, especially abcl because of the java intergration possibilities.
>
Another very nice option is to use SBCL together with SLIME which makes
for a very powerful GUI. While perhaps not as beautiful as Lispworks, I
actually prefer some of SLIME's functions versus Lispworks. For creating
GUIs there is always Ltk :)
Peter
--
pet project: http://dawn.netcologne.de
homepage: http://www.peter-herth.de
lisp stuff: http://www.peter-herth.de/lisp.html
get Ltk here: http://www.peter-herth.de/ltk/
Why does this come up every month?
I always thought it would be easier to search the web first, and
then go to a newsgroup (anyway, that's what i usually do for
information).
Still, this ng gets the same "What Lisp on the Mac?" question on a
regular interval.
*puzzled*
In article <···············@individual.net>,
Ulrich Hobelmann <···········@web.de> wrote:
> Why does this come up every month?
Clearly, it is a FAQ, which is why we've posted a fairly comprehensive
answer at:
<http://lisp.tech.coop/Which%20Common%20Lisp%20for%20Macintosh>
Again, this page is editable, so people are free to make additions and
corrections - no permission is needed, and this page does not "belong"
to me, or anyone else who has contributed to it.