[Mono-osx] (no subject)

[Andrew Satori]

I wanted to take a day to think through my response to this, because  
it's an issue that I have strong opinions and those tend to come  
across too strongly in email :-)

> Unfortunately there are many negatives here:

They really aren't negatives, they are opportunities for third party  
vendors to make a buck, or maybe several thousands of bucks :-).


> Java seems to run slowly on MacOSX

This is emphatically not true.  Java is not and slower on MacOS X  
than on any other platform, and it's better than many.  That's not  
the issue.  The issue is that Java User Interfaces tend to be slow  
and not have a native look and feel, nor support native functionality  
like robust drag and drop and services.  These basic weaknesses make  
any Java based UI that isn't built on Cocoa less desirable and less  
comfortable for most Mac users.  This excludes the X-Windows  
switchers for whom using 10 toolkits and mismatched user interfaces  
that don't interact with each other well is the norm, not the exception.

> Lack of effort on Mac specific work for Mono

I think you misunderstood this section of the discussion.  Mono on  
Mac gets an inordinate amount of work when you consider how small the  
actual community is.  Though I don't have access to the numbers, this  
list is probably 1/100th the size of the Mono lists, and it's  
probably an even smaller portion of the overall Mono community.  Mono  
on the Mac, is at it's core, in good shape.  The things that are on  
the periphery are less so, but XSP and Mod_mono are in good shape.   
Managed Windows Forms is not, and quite frankly, I never expect it to  
be.  It's design is such that even if it does get good support, it  
will always have that Java User Interface issue of simply not being  
'native' and therefore not the first choice for many Mac users who  
are fanatically picky about he UI.  Look at the hubbub every time  
Apple tweaks a UI like iTunes, QuickTime, Safari, or Finder.

> Lack of effort on Mac specific work for IDEs

Again, this is not a problem, it's an opportunity.  If a team were to  
build a Mac based IDE that leveraged the things the Mac does well  
along with the Power of Mono, the potential to build a 'killer' or  
'tractor' app is there.  Now for my strong opinion, which ties into  
the next remark.

The proper IDE is the one that already exists.

> No easy way to integrate Mono into XCode

Just because it isn't easy, doesn't mean it's not the right way.  
There seem to be two camps regarding Xcode.  Those that hate it, this  
is predominantly the CodeWarrior user base, with a fair number of  
Windows switchers being among this group.  Then there are those that  
are comfortable with it.  There really isn't a love fest with it, it  
still lacks to many features that power users want to make it a love  
fest.  Don't let these things divert you from the important things.

Xcode _is_ for better or worse, the development platform for the  
MacOS X.  Every new Mac comes with it as an optional install, and as  
such, it is going to be around and it's on the cheap.

Xcode has an incredible amount of power under the hood, and given  
documented, publicly available access to the information to extend  
Xcode, it would be easier to plug Mono and C# (and others) into Xcode  
to turn it into a Visual Studio like toolset. The foundations are  
already there, you can see it by looking at how AppleScript Studio,  
WebObjects, and most imporantly the Core Data data modeler  
(EOModeler) has been retooled within XCode.  These are all  
implemented as plugins.

What would be required? ( these are rough, there is some detail in  
this that I'm not covering )

Syntax Styling for C#.  ( initial pass done, doesn't support code  
completion from the library )
Code Completion Plugin.  ( need documentation, or class dump the  
interface and creative hacking )
CompilerSpec Plugin for mcs ( need documentation, or class dump the  
interface )
Lexical Parser for mcs error message ( time consuming, not done )
Spec files for integration into native build system ( currently using  
makefiles )
Installer to put the pieces in place ( fairly easy once the other  
things are done )

Once those things are done, you really only need one additional hack  
or documentation to add another set of goodies, and that is to class  
dump and hack how to add custom editors / viewers like the data  
modeler into the Xcode.  With that, it would then be feasible to  
build a data browser and as(p|c|m|a)x editor using a mixture of  
WebCore and some grisly custom code to convert prepocessed code into  
layout elements in design mode.

So, we aren't talking impossible, we are talking a big task, and one  
that I personally think has a commercially viable market if an OSS  
group isn't willing to step up.

> Main issue for me is that Apple is not interested, at least  
> publicly, in the modern OO languages as a developer platform for  
> OSX. Objective C and Cocoa is what they want people to use.

Apple can't afford to be interested right now, at least not  
officially.  They don't have the resources, and there is the  
potential for a legal mess until Novell finishes it's legal  
assessment of the vulnerability to Microsoft.  I can't help but think  
that this discussion has been had at fairly high levels within Apple,  
which we tend to forget is smaller than it may sometimes appear.

> ObjC-Cocoa is very good but unfortunately for Apple many developers  
> know and like Java and/or C# and aren't willing to learn Objective  
> C and Cocoa.

I think you are correct, however, I don't think that's a huge concern  
for them right now, there are enough people who are willing to learn,  
in addition to the ability to continue to use C and C++ behind the  
scenes that Apple doesn't see the need.  What they are saying is that  
future User Interface development shall be in IB/ObjC, but you are  
welcomed and encouraged to use your preexisting code in it's current  
form from there, and that includes Java via the bridge.

> I posted a reply to John Siracusa's post at Ars Technica on the  
> subject and wrote to jobs at apple.com (never got a reply!)
>
> I hope somehow that Apple realise that they are badly behind other  
> platforms in this respect but I fear that the high management at  
> Apple in this area are Cocoa veterans and being open to new ideas  
> when you are an expert is very difficult psychologically.

It's not an issue of behind, they aren't, in reality, they are  
*still* ahead.  the IB + Objective C approach is still far ahead of  
the Forms / Event designs of Windows and X-Windows.  Avalon and all  
the Longhorn/Vista changes in the model don't change this at all.   
What Apple does have is a paradigm shift that is a little tough for  
switcher developer to wrap their heads around.  It took me a full  
year before I got around to really sitting down with IB and Objective  
C.  Today, my frustration is that I *can't* use the same paradigm on  
Windows and Linux (and the person that says Gorm & GnuStep gets a  
slimy wet trout to the head, see my above statements about native LnF  
and usability)

> For now I still think that Eclipse is the best option given its  
> features, relative maturity, industry backing and huge following.  
> It should scream on a G5 2.0GHz so the push should be on fixing  
> Apple Java and/or Eclipse so that it does fly.

And I would push that it's not.  Eclipse rocks for Java developer's,  
but for C# & Mono, I have a real issue pushing an app written in Java  
as the IDE of choice.  Sorry, but this is kinda like standing there  
preaching that a Mac is better, and using a Dell to do so.  No thanks.

> I have raised a performance bug in Eclipse which caused it to crawl  
> during a Crtl+1 quick fix so further such fixes may speed it up.
>
> Perhaps the move to x86 will help since most dev is on x86 so the  
> Mac should benefit from hardware optimizations that are probably  
> absent on PPC.

The 'move' to x86 will bring alot of change, not all of it for the  
better.  The optimizations as it were have been there.  Cocoa's and  
more importantly all of the underlying technology that came from NeXT  
originated on the Motorolla 80x0 chips, but has been on Intel x86 for  
close to 10 years.  Those optimizations certainly exist, and GCC  
basically blows on PPC. So yes, I would expect native x86 apps to  
behave better and perform better on x86, but the limitations of x86  
will introduce performance ceilings in other aspects, and quite  
frankly, none of them are relevant to Mono and the usage or  
development of an IDE.

Sorry for being so verbose, but I have strong opinions on this, and  
yes, I *really* like Mono on the Mac, and I simply feel that Xcode  
should be the environment for Mac dev, regardless of language, and  
that the basics are in place for it to be a top notch C# dev  
environment, where we can focus on C# and Mono plugins and let Apple  
work on the things that make Xcode better for everyone.


Andy