[Openmcl-devel] [info-mcl] MCL 6.0 preview
plkrueger at comcast.net
Tue Nov 9 19:43:14 UTC 2010
Deja vu; seems like we've had similar discussions in the past ...
On Nov 9, 2010, at 11:44 AM, Robert Goldman wrote:
> Maybe when this is checked in, Paul and/or the Clozure gang can offer a
> tutorial at an upcoming ILC!
I'll start with a TCLispers talk after I get it checked in. January? For those of you who don't want to come to Minneapolis just to hear me talk, they are typically recorded and made available to anyone. See the TCLispers web site: http://tclispers.org/.
I'd have to give an ILC presentation some thought. I'm not really trying to create a movement here, I mostly did this so I could use it myself and contributed it to save others from having to go through my learning curve. I really didn't appreciate exactly how long that learning curve would be.
> But please don't assume that we all know IB and Objective C! It's OK if
> the tool is primarily for people who know Objective C --- a fully-lisp
> approach is probably not realistic.
We're both old enough to have seen (and participated in) Lisp-only GUI approaches. There is a section early in my tutorial that explains in more detail why I think these inevitably fail. It's hard to use Cocoa objects without understanding enough Objective-C to use them effectively. But Objective-C is strongly reminiscent of Smalltalk, so if you had any exposure to that it shouldn't really be a big learning curve. It's not at all like C++, which I consider to be a gross abomination (and I used C++ myself as a developer for several years). Much of Objective-C is devoted to various data types and I have a substantial amount of code that automatically converts back and forth between those and Lisp types. Do you need to pass an NSDictionary object to some Objective-C method as an argument? No problem; you start with a Lisp hash table and make a Lisp call to get what you need. Is some Objective-C method returning an NSArray that you need to use in Lisp? Again, a simple Lisp function call results in a Lisp list or array (your choice). I can't make using Cocoa totally transparent without falling into the trap of dooming my own code to obsolescence every time Apple has a new release. But I think I made a reasonable start on making it fairly easy for Lisp developers to use.
I should also point out that creating stand-alone applications involves understanding quite a bit about Apple application bundles; their structure and content. Although my GUI makes it fairly straightforward to create and manage those, inevitably developers will want to do something a little more complex that requires them to more directly manipulate things like the Info.plist or other bundle resource files.
> But invite the rest of us to join you!
What sort of invitation did you have in mind? Once I put the source in my contrib directory it's freely available for anyone to use. I've used the MIT license for all source which is what the Cocotron people use and it is pretty liberal about the uses that people can make of it. If someone wants to port it to SBCL or Clojure or whatever, they have my blessing and I'll even answer questions if I can.
> Right now there's a huge up-front cost that I'd have to bite off on
> faith. I'd have to learn a lot about Objective C and Cocoa, hoping that
> it will let me do something cool. I have to weigh this against, e.g.,
> sinking that time in to the browser platform, Gtk, qt, or the Java
> platform (say if I want to use ABCL, kawa, or Clojure). It'd be a lot
> easier if we knew for sure there was something cool at the end of the
For me, the choice of what sort of GUI you want to use depends mostly on how you want to deploy the application. If you want to provide a web app that is accessible via a browser, then what I'm doing probably isn't all that useful. But if you want to provide an app that runs on a Mac like any other native app, then I what I'm doing is more relevant. But you're absolutely correct that there is a cost to be paid for learning how to do this.
Of course that's why I create examples, so people can more easily learn how to use my code. But it still may not be all that relevant unless it catches on with others and some start to improve on it. I'm not likely to create a large-scale commercial app anytime soon, so having someone use if for something like that may be necessary to convince you and others of its value. Also, IB is specific to Apple although Cocotron may allow development on Apple platforms and deployment to others; that's more or less their stated intent. I haven't tried to do that myself and don't expect to do so.
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel