Apple is deprecating Java! See: developer.apple.com. Quote:
Java Deprecation
As of the release of Java for Mac OS X 10.6 Update 3, the version of Java that is ported by Apple, and that ships with Mac OS X, is deprecated.
This means that the Apple-produced runtime will not be maintained at the same level, and may be removed from future versions of Mac OS X. The Java runtime shipping in Mac OS X 10.6 Snow Leopard, and Mac OS X 10.5 Leopard, will continue to be supported and maintained through the standard support cycles of those products.
Am so glad of this. Sooo glad. Death to you, Sun Microsystems, and your Java fuck. Thank you for your incredible unscrupulous marketing lies and lawsuit gaming.
12 years ago, the creator of tcl, John K Ousterhout, wrote a well known article〈Scripting: Higher Level Programming for the 21st Century〉 at Source. It is finally coming true in recent years.
* Xah's Java Logo * Jargons of Info Tech Industry * What are OOP's Jargons and Complexities * The Tech Geekers and Software Engineering * Proliferation of Computing Languages
On 2010-10-22 01:45:22 +0100, MarkHanif...@gmail.com said:
> Great....now if I promise to buy a Mac can we get Dylan back?
If you buy a mac you will probably get, in due course, an entirely closed appliance. Don't think deprecating Java is a good thing: it's part of the process by which Apple are closing the system down.
On 22 Okt., 12:06, Tim Bradshaw <t...@tfeb.org> wrote:
> On 2010-10-22 01:45:22 +0100, MarkHanif...@gmail.com said:
> > Great....now if I promise to buy a Mac can we get Dylan back?
> If you buy a mac you will probably get, in due course, an entirely > closed appliance. Don't think deprecating Java is a good thing: it's > part of the process by which Apple are closing the system down.
Apple is not deprecating Java, it is only deprecating their own distribution of it.
Like on other platforms SUN/Oracle will have to provide it - or other vendors of Java implementations, like IBM.
"jos...@corporate-world.lisp.de" <jos...@lisp.de> writes: > On 22 Okt., 12:06, Tim Bradshaw <t...@tfeb.org> wrote: >> On 2010-10-22 01:45:22 +0100, MarkHanif...@gmail.com said:
>> > Great....now if I promise to buy a Mac can we get Dylan back?
>> If you buy a mac you will probably get, in due course, an entirely >> closed appliance. Don't think deprecating Java is a good thing: it's >> part of the process by which Apple are closing the system down.
> Apple is not deprecating Java, it is only deprecating their own > distribution of it.
> Like on other platforms SUN/Oracle will have to provide it - or other > vendors of Java implementations, like IBM.
But at the same time, that renders Java an optionnal package, which is a basis to exclude applications requiring it from the MacStore (and obviously from the iOS AppStore too).
That doesn't prevent MacOSX applications requiring these optional packages to be sold, but not thru Apple.
On 2010-10-22 11:32:40 +0100, jos...@corporate-world.lisp.de said:
> Like on other platforms SUN/Oracle will have to provide it - or other > vendors of Java implementations, like IBM.
It's probably a significant amount of work to to platform-integration stuff unless Apple give away theirs. The result is likely to be, at best, an implementation which uses X11 and suffers from the resulting catastriphic look&feel failures.
So it is almost certainly dead, I think. As others have pointed out, this is probably only partly about closing down OS X: it's also about hurting people who want to use a mac to develop for Android.
On Oct 22, 5:06 am, Tim Bradshaw <t...@tfeb.org> wrote:
> On 2010-10-22 01:45:22 +0100, MarkHanif...@gmail.com said:
> > Great....now if I promise to buy a Mac can we get Dylan back?
> If you buy a mac you will probably get, in due course, an entirely > closed appliance. Don't think deprecating Java is a good thing: it's > part of the process by which Apple are closing the system down.
On 22 Okt., 13:15, Tim Bradshaw <t...@tfeb.org> wrote:
> On 2010-10-22 11:32:40 +0100, jos...@corporate-world.lisp.de said:
> > Like on other platforms SUN/Oracle will have to provide it - or other > > vendors of Java implementations, like IBM.
> It's probably a significant amount of work to to platform-integration > stuff unless Apple give away theirs. The result is likely to be, at > best, an implementation which uses X11 and suffers from the resulting > catastriphic look&feel failures.
Microsoft does not create the Windows version. Still somebody does.
The look&feel of Java applications was never good on the Mac. Probably it is never good anywhere. Apple has given up on supporting the Cocoa bridge for Java long ago.
It also does not matter much, since not much Java programming is done for Mac UIs. In corporate environments much Java use is simply server-side programming. There are some Java applications with desktop UIs, but they weren't never much developed for the Mac or even on the Mac.
> So it is almost certainly dead, I think. As others have pointed out, > this is probably only partly about closing down OS X: it's also about > hurting people who want to use a mac to develop for Android.
Doesn't matter. Android does not use Mac UIs. All that is needed to develop for Android is a relatively plain Java for it.
The thing is simply that there are few programming environments who can create good Mac-like applications. Apple concentrates on their tools and if developers want something else, they need to use open source tools (which most are not really good) or go to other vendors. If for example IntelliJ wants to provide their commercial Java IDE for the Mac also in the future, they have to deliver a suitable Java implementation for it (or use some other).
The relevance of Java for GUI application is approaching zero. Apple's capability to provide a Java implementation is also approaching zero - Oracle/IBM/... owns that business and if they want to address Java developers, they should provide the implementation. That's also not rocket science, since the ports are done, the compilers are there. There is value for Apple in providing their port of the Java tools.
Similar on the Lisp side. In recent years I have seen very very few useful GUI-based Lisp apps, on the Mac. That's not the fault of Apple. It is simply that there are few developers using Lisp to deliver apps on the Mac. It simply does not matter. Even CCL has not seen a relevant amount of useful Mac applications - it simply is not mature enough on the library side. The only Lisp option that currently creates useful result is LispWorks - which is great, but a bit expensive.
These people should stop bash Apple and show their commitment to their tools and languages. Talk does not matter. Applications do.
Btw., I have a LispWorks faceless application which runs CL-HTTP. I was thinking about turning that into a real Mac application and see if one could enter it into Apple's app store. It's native, doesn't use deprecated technology, ... I can't see why Apple should reject it.
> "jos...@corporate-world.lisp.de" <jos...@lisp.de> writes: > > On 22 Okt., 12:06, Tim Bradshaw <t...@tfeb.org> wrote: > >> On 2010-10-22 01:45:22 +0100, MarkHanif...@gmail.com said:
> >> > Great....now if I promise to buy a Mac can we get Dylan back?
> >> If you buy a mac you will probably get, in due course, an entirely > >> closed appliance. Don't think deprecating Java is a good thing: it's > >> part of the process by which Apple are closing the system down.
> > Apple is not deprecating Java, it is only deprecating their own > > distribution of it.
> > Like on other platforms SUN/Oracle will have to provide it - or other > > vendors of Java implementations, like IBM.
> But at the same time, that renders Java an optionnal package, which is a > basis to exclude applications requiring it from the MacStore (and > obviously from the iOS AppStore too).
> That doesn't prevent MacOSX applications requiring these optional > packages to be sold, but not thru Apple.
Correct. Like Apple's Rosetta. It is optional, so Apple won't distribute software based on it.
If Java applications come with the necessary runtime bundled into the application, it could be distributed.
Like in LispWorks. One can generate a single executable which contains all the necessary stuff: runtime, library, application. LispWorks applications don't need any optional runtime to be installed. The executable has some size, but that does not matter, since people even download multi-hundred megabyte apps for the iPad from the Appstore. A typical LispWorks app is a fraction. If somebody can download a navigation application with hundreds of megabytes size from an appstore, a foto magazine with hundreds of megabytes, one could certainly download a ten MB LispWorks application from some appstore.
On 22 Okt., 15:59, "jos...@corporate-world.lisp.de" <jos...@lisp.de> wrote:
> The relevance of Java for GUI application is approaching zero. > Apple's capability to provide a Java implementation > is also approaching zero - Oracle/IBM/... owns that business > and if they want to address Java developers, they > should provide the implementation. That's also not rocket > science, since the ports are done, the compilers are there. > There is value for Apple in providing their port of the Java > tools.
I meant, there is little value for Apple in doing so...
On 2010-10-22 14:59:57 +0100, jos...@corporate-world.lisp.de said:
> Microsoft does not create the Windows version. Still somebody does.
Because windows has much, much more market share than OS X (and historically had even more)
> Doesn't matter. Android does not use Mac UIs. > All that is needed to develop for Android is a relatively plain Java > for it.
I don't know what people use but I bet it's Eclipse or something like that: I bet it will be come big complicated GUI-based thing anyay. I don't know to what extent Eclipse depends on the native GUI libraries though.
Incidentally, I'm not bashing Apple: I think what they're doing is pretty smart (not the Java stuff, the closed-ecosystem stuff that has done so well for iPhone/iPad and (I think) may well be looming for mac - after all it's how macs started). It's just hostile to anything I care about.
> On 2010-10-22 14:59:57 +0100, jos...@corporate-world.lisp.de said:
> > Microsoft does not create the Windows version. Still somebody does.
> Because windows has much, much more market share than OS X (and > historically had even more)
> > Doesn't matter. Android does not use Mac UIs. > > All that is needed to develop for Android is a relatively plain Java > > for it.
> I don't know what people use but I bet it's Eclipse or something like > that: I bet it will be come big complicated GUI-based thing anyay. I > don't know to what extent Eclipse depends on the native GUI libraries > though.
SWT, but that is no rocket science. If there is enough interest in having a useful SWT port for the Mac somebody will do it. If not, it may deserve to die...
> Incidentally, I'm not bashing Apple: I think what they're doing is > pretty smart (not the Java stuff, the closed-ecosystem stuff that has > done so well for iPhone/iPad and (I think) may well be looming for mac > - after all it's how macs started). It's just hostile to anything I > care about.
I don't think Apple is hostile. They just don't care much about stuff that's not used much anyway or which the developing company failed to improve (for example Flash).
On Oct 21, 9:09 am, Xah Lee <xah...@gmail.com> wrote:
> Apple is deprecating Java! See: developer.apple.com. Quote:
> Java Deprecation
> As of the release of Java for Mac OS X 10.6 Update 3, the version > of Java that is ported by Apple, and that ships with Mac OS X, is > deprecated.
> This means that the Apple-produced runtime will not be maintained > at the same level, and may be removed from future versions of Mac OS > X. The Java runtime shipping in Mac OS X 10.6 Snow Leopard, and Mac OS > X 10.5 Leopard, will continue to be supported and maintained through > the standard support cycles of those products.
As a former Sun employee I can say the world has deprecated us why not Apple.
> Am so glad of this. Sooo glad. Death to you, Sun Microsystems, and > your Java fuck.
Is this language really needed? (turn other-cheek)
>Thank you for your incredible unscrupulous marketing > lies and lawsuit gaming.
> 12 years ago, the creator of tcl, John K Ousterhout, wrote a well > known article〈Scripting: Higher Level Programming for the 21st > Century〉 at Source. It is finally coming true in recent years.
> * Xah's Java Logo > * Jargons of Info Tech Industry > * What are OOP's Jargons and Complexities > * The Tech Geekers and Software Engineering > * Proliferation of Computing Languages
On Fri, 22 Oct 2010 12:15:47 +0100, Tim Bradshaw wrote: > So it is almost certainly dead, I think. As others have pointed out, > this is probably only partly about closing down OS X: it's also about > hurting people who want to use a mac to develop for Android.
I think that it's more likely to be a side-effect of their rising standards for application appearance, their desire to be able to control or switch processor architectures easily.
The user-experience is the big issue, I think. It is the same issue as flash on the iPhone. I think that what we're seeing is a final realization that cross-platform GUI toolkits simply aren't good enough, and can't be, because the underlying models of what's going on and how to achieve it are quite different. Well, Windows and some of the Linux GUIs are relatively similar, but Cocoa is quite different. A cross-platform toolkit that follows a Windows/Linux model, but uses a Cocoa layer to draw the results is still going to feel alien to Mac users, and the in-window menu bar is just the beginning. A cross-platform toolkit that doesn't even use the Cocoa layer, but renders all of the widgets in look-alike fashion (swing) is doomed to suffer many small aspects of brokenness.
Up to now, it seems that supporting different-feeling applications, in order to have those applications at all, has been an acceptable trade- off. Perhaps growing success in the market place makes Apple think that they are in a position to demand that software vendors support their platform "natively."
I think that we're seeing a rejection of the whole notion of "cross- platform GUI".
Andrew Reilly <areilly...@bigpond.net.au> writes: > The user-experience is the big issue, I think. It is the same issue as > flash on the iPhone.
I think Flash on the iPhone is not only a user-experience issue, but also a battery issue.
> I think that what we're seeing is a final realization that > cross-platform GUI toolkits simply aren't good enough, and can't be, > because the underlying models of what's going on and how to achieve it > are quite different.
You may be right, but Lispworks CAPI applications tend to work out better than any java application I've seen so far. -- (espen)
On 23 Okt., 00:45, Espen Vestre <es...@vestre.net> wrote:
> Andrew Reilly <areilly...@bigpond.net.au> writes: > > The user-experience is the big issue, I think. It is the same issue as > > flash on the iPhone.
> I think Flash on the iPhone is not only a user-experience issue, but > also a battery issue.
Both, I would not be able to say where it is worse.
> > I think that what we're seeing is a final realization that > > cross-platform GUI toolkits simply aren't good enough, and can't be, > > because the underlying models of what's going on and how to achieve it > > are quite different.
> You may be right, but Lispworks CAPI applications tend to work out > better than any java application I've seen so far.
Isn't that ironic? LispWorks 6 is totally snappy and looks/feels great. I'm using the 64bit Cocoa-based version and it is quite great.
Compare that to the Java-based IDEs (Eclipse, IntelliJ, ...) which are providing a lot of functionality, but always feel a bit sluggish and where the UI is complex and kind of ugly.
"jos...@corporate-world.lisp.de" <jos...@lisp.de> writes: > On 22 Okt., 12:06, Tim Bradshaw <t...@tfeb.org> wrote: >> On 2010-10-22 01:45:22 +0100, MarkHanif...@gmail.com said:
>> > Great....now if I promise to buy a Mac can we get Dylan back?
>> If you buy a mac you will probably get, in due course, an entirely >> closed appliance. Don't think deprecating Java is a good thing: it's >> part of the process by which Apple are closing the system down.
> Apple is not deprecating Java, it is only deprecating their own > distribution of it.
> Like on other platforms SUN/Oracle will have to provide it - or other > vendors of Java implementations, like IBM.
I think you can forget about IBM. They announced a wek or so back that they were going to put all their efforts into supporting openJDK now.
Essentially, anyone who is expecting Java to go away any time soon is woefully mistaken. If anything, the increase in focus on openJDK by major players will likely prolong its life.
Personally, this may be a good thing. While I hated using Java back in the 1.0 and 1.1 versions and found the environment a major pain to maintain, I have to say that more recent experiences as a result of looking at clojure, indicate huge improvements. I still don't like Java and still think it is an overly verbose and boring language to use with too much bloat, but at least the environment has improved and getting things setup and then maintaining them seems to have become far less frustrating. This is good because there are some interesting things happening on the jvm.
As an example, I recently wrote a very simple utility in clojure which I was able to get deployed in our production environments with absolutely no problems because it was just a jar file. A similar utility written in CL was rejected on the grounds the admins were not prepared to maintain a CL environment (a native executable was also rejected for other largely political and ill-informed technical reasons). I was going to try ABCL, but settled on clojure for no other reason other than I wanted to try writing something in it. I also got past the most significant bottleneck with CL - no available database access library that would allow calling of stored procedures etc. Clojure, having access to the java APIs allows the use of JDBC. (I suspect you might be able to do something similar with ABCL as well).
While Java as a programming language is IMO limited, JVM as a deployment platform has some very interesting possibilities. Languages like clojure, scalar and even jRuby or jPython could mean that as programmers, we may not be as constrained by management's concern over enterprise environment maintenance and administration. While there would always be the maintenance concern over anything used in production that is written in a language only one person knows, being able to use one deployment infrastructure is likely to provide some more freedom for programmers.
> "jos...@corporate-world.lisp.de" <jos...@lisp.de> writes: > > On 22 Okt., 12:06, Tim Bradshaw <t...@tfeb.org> wrote: > >> On 2010-10-22 01:45:22 +0100, MarkHanif...@gmail.com said:
> >> > Great....now if I promise to buy a Mac can we get Dylan back?
> >> If you buy a mac you will probably get, in due course, an entirely > >> closed appliance. Don't think deprecating Java is a good thing: it's > >> part of the process by which Apple are closing the system down.
> > Apple is not deprecating Java, it is only deprecating their own > > distribution of it.
> > Like on other platforms SUN/Oracle will have to provide it - or other > > vendors of Java implementations, like IBM.
> I think you can forget about IBM. They announced a wek or so back that > they were going to put all their efforts into supporting openJDK now.
No, they didn't say that. They said that they will support OpenJDK instead of Apache Harmony.
This has no effect on the fact that IBM has its own Java implementation.
I don't think IBM will support it on the Mac, but what I wanted to say that there are multiple vendors of Java Virtual Machines and Java compilers. If Apple does not support their own port of some JVM (the SUN JVM), somebody else might. SUN supports Hotspot on Windows, Linux and Solaris.
The company I currently work for is interested in this stuff, but personally I don't care. Personally I'm happy with the native CL implementations which run great under Mac OS X.
Andrew Reilly <areilly...@bigpond.net.au> writes: > On Fri, 22 Oct 2010 12:15:47 +0100, Tim Bradshaw wrote:
>> So it is almost certainly dead, I think. As others have pointed out, >> this is probably only partly about closing down OS X: it's also about >> hurting people who want to use a mac to develop for Android.
> I think that it's more likely to be a side-effect of their rising > standards for application appearance, their desire to be able to control > or switch processor architectures easily.
> The user-experience is the big issue, I think. It is the same issue as > flash on the iPhone. I think that what we're seeing is a final > realization that cross-platform GUI toolkits simply aren't good enough, > and can't be, because the underlying models of what's going on and how to > achieve it are quite different. Well, Windows and some of the Linux GUIs > are relatively similar, but Cocoa is quite different. A cross-platform > toolkit that follows a Windows/Linux model, but uses a Cocoa layer to draw > the results is still going to feel alien to Mac users, and the in-window > menu bar is just the beginning. A cross-platform toolkit that doesn't > even use the Cocoa layer, but renders all of the widgets in look-alike > fashion (swing) is doomed to suffer many small aspects of brokenness.
Cross platform GUI (even with native look and feel) could work. If it wasn't a moving target. But since Apple is in the fashion business since 2000, they have to change the look of their GUI every couple of years, and the cross platform GUI providers just don't have the resources to follow.
And of course, changing the look is the only way you can get recuring sales, since otherwise normal people wouldn't see the point in upgrading.
> Up to now, it seems that supporting different-feeling applications, in > order to have those applications at all, has been an acceptable trade- > off. Perhaps growing success in the market place makes Apple think that > they are in a position to demand that software vendors support their > platform "natively."
> I think that we're seeing a rejection of the whole notion of "cross- > platform GUI".
That said, the customers of Apple themselves are quite discriminating and reject applications that are not up to Apple's standard. I've seen this occur several times since 1984.
On the other hand, GNUstep has not had much of a success either in the other platforms, so perhaps the others are discriminating too.
"jos...@corporate-world.lisp.de" <jos...@lisp.de> writes: > On 23 Okt., 01:50, Tim X <t...@nospam.dev.null> wrote: >> "jos...@corporate-world.lisp.de" <jos...@lisp.de> writes: >> > On 22 Okt., 12:06, Tim Bradshaw <t...@tfeb.org> wrote: >> >> On 2010-10-22 01:45:22 +0100, MarkHanif...@gmail.com said:
>> >> > Great....now if I promise to buy a Mac can we get Dylan back?
>> >> If you buy a mac you will probably get, in due course, an entirely >> >> closed appliance. Don't think deprecating Java is a good thing: it's >> >> part of the process by which Apple are closing the system down.
>> > Apple is not deprecating Java, it is only deprecating their own >> > distribution of it.
>> > Like on other platforms SUN/Oracle will have to provide it - or other >> > vendors of Java implementations, like IBM.
>> I think you can forget about IBM. They announced a wek or so back that >> they were going to put all their efforts into supporting openJDK now.
> No, they didn't say that. They said that they will support OpenJDK > instead of Apache Harmony.
> This has no effect on the fact that IBM has its own Java > implementation.
OK, I was going on a secondary source which could very well be incorect. While it did clearly state IBM was no longer going to put support behind Harmony, it was also suggested that, while IBM was not planning to stop support of their Java implementation, they would not be continuing to develop/extend it further, instead they would move more towards using the openJDK and incresingly put more of their resources into that version.
In reality and based on past behavior, they will probably hedge their bets for a while yet and see what happens with openJDK and what Oracle does.
> I don't think IBM will support it on the Mac, but what I wanted to > say that there are multiple vendors of Java Virtual Machines and Java > compilers. > If Apple does not support their own port of some JVM (the SUN JVM), > somebody > else might. SUN supports Hotspot on Windows, Linux and Solaris.
I suspect if the demand is there, openJDK will be supported.
> The company I currently work for is interested in this stuff, but > personally I don't care. Personally I'm happy with the native CL > implementations > which run great under Mac OS X.
Your lucky. No way can I get anything written in CL onto production systems (even when compiled to native exe). Of course this is from management that states our users are all windows based when we have clear figures that indicate nearly 40% are Mac and another 8% are Linux.
On Fri, 22 Oct 2010 16:06:45 -0700, jos...@corporate-world.lisp.de wrote: >> You may be right, but Lispworks CAPI applications tend to work out >> better than any java application I've seen so far.
> Isn't that ironic? LispWorks 6 is totally snappy and looks/feels great. > I'm using the 64bit Cocoa-based version and it is quite great.
Is that because the LispWorks people wrote a Cocoa GUI for their IDE, after making the necessary Objective-C method invocation and object management schims, or have they just made a sufficiently advanced and abstract cross-platform toolkit? I.e., is the IDE GUI code on Mac the same as the IDE GUI code on Windows or Unix? (I'm afraid that I've not used it on any platform.)
Certainly Lisp has the semantic flexibility to be able to interact in the Smalltalk-ish way that makes Objective-C and Cocoa a good bit different from Java or the Windows or GTK API(s).
I don't think that it is ultimately a language issue, but *is* an object model, GUI API and method invocation semantics issue, and some languages make things difficult for themselves by being inflexible about their object models and GUI APIs...
Andrew Reilly <areilly...@bigpond.net.au> writes: > On Fri, 22 Oct 2010 16:06:45 -0700, jos...@corporate-world.lisp.de wrote:
>>> You may be right, but Lispworks CAPI applications tend to work out >>> better than any java application I've seen so far.
>> Isn't that ironic? LispWorks 6 is totally snappy and looks/feels great. >> I'm using the 64bit Cocoa-based version and it is quite great.
> Is that because the LispWorks people wrote a Cocoa GUI for their IDE, > after making the necessary Objective-C method invocation and object > management schims, or have they just made a sufficiently advanced and > abstract cross-platform toolkit? I.e., is the IDE GUI code on Mac the > same as the IDE GUI code on Windows or Unix? (I'm afraid that I've not > used it on any platform.)
> Certainly Lisp has the semantic flexibility to be able to interact in the > Smalltalk-ish way that makes Objective-C and Cocoa a good bit different > from Java or the Windows or GTK API(s).
> I don't think that it is ultimately a language issue, but *is* an object > model, GUI API and method invocation semantics issue, and some languages > make things difficult for themselves by being inflexible about their > object models and GUI APIs...
You can have different object models cohabiting in a lisp application.
I would not try to make a CLOS subclass of NSView, anymore than I would make a CLOS object a subprototype of a KB prototype.
On 23 Okt., 06:25, Andrew Reilly <areilly...@bigpond.net.au> wrote:
> On Fri, 22 Oct 2010 16:06:45 -0700, jos...@corporate-world.lisp.de wrote: > >> You may be right, but Lispworks CAPI applications tend to work out > >> better than any java application I've seen so far.
> > Isn't that ironic? LispWorks 6 is totally snappy and looks/feels great. > > I'm using the 64bit Cocoa-based version and it is quite great.
> Is that because the LispWorks people wrote a Cocoa GUI for their IDE, > after making the necessary Objective-C method invocation and object > management schims, or have they just made a sufficiently advanced and > abstract cross-platform toolkit? I.e., is the IDE GUI code on Mac the > same as the IDE GUI code on Windows or Unix? (I'm afraid that I've not > used it on any platform.)
In the early days LispWorks had a nice GUI toolkit for X11 systems on top of CLX/CLUE. Then the demand came up for a native Windows based port of LispWorks. That caused them to develop CAPI, which was abstracted to be cross-platform over X11/Motif and Windows. CLX/CLUE was gone.
Over the years this has been improved. When the Mac got OS X and Cocoa, eventually LispWorks was ported to that platform with a port of CAPI on top of Cocoa. The first versions were raw, but the current LispWorks 6 version is quite a bit improved. For example the toolbars in the windows are now really the complex native based toolbars of the Mac with the native customization feature. There are some weak spots, but one thing stands out: on my MacBook Pro the UI doesn't lag and is not sluggish. One gets the typical animations: the print dialog, the open dialog, slide down. Not that they are really useful, but it provides a consistent feeling across applications, including LispWorks.
The Apple Cocoa framework has some nice stuff, but from a programming side it has some limitations (like the need to use the main thread for UI code).
With LispWorks 6 CAPI was improved further and a new native GTK+ port has been added. The old X11/Motif backend is now 'deprecated'.
I'm not saying that CAPI is perfect or deep enough, but if you look at some at the basic UI look&feel, it isn't alien at all. Something that is important for a Mac user. It's also not slavishly Mac, the tools still have extended commands, etc.
> Certainly Lisp has the semantic flexibility to be able to interact in the > Smalltalk-ish way that makes Objective-C and Cocoa a good bit different > from Java or the Windows or GTK API(s).
> I don't think that it is ultimately a language issue, but *is* an object > model, GUI API and method invocation semantics issue, and some languages > make things difficult for themselves by being inflexible about their > object models and GUI APIs...
> I think that it's more likely to be a side-effect of their rising > standards for application appearance, their desire to be able to control > or switch processor architectures easily.
I think you're agreeing with me, though you may not think so. What I want is a platform where I can write or use applications which are as ugly and non-conformant as anything if I want to, and not one which is "curated" for me by some higher power.
Of course, one might ask why such curation is needed - is there somehow a worry that bad user-interface design will beat out good? Maybe there's some other, simpler, explanation.
