[Mono-osx] (no subject)
dru at druware.com
Sun Oct 30 10:11:09 EST 2005
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
Lexical Parser for mcs error message ( time consuming, not done )
Spec files for integration into native build system ( currently using
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
> 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.
More information about the Mono-osx