[Mono-osx] Re: Mono-osx Digest, Vol 7, Issue 8

[Timothy Mowlem]

Hello Peter,


> -----------------------------
>
> Message: 4
> Date: Mon, 31 Oct 2005 12:00:36 -0800
> From: Peter Loron <peterl at standingwave.org>
> Subject: Re: [Mono-osx] (no subject)
> To: Andrew Satori <dru at druware.com>
> Cc: Mono-osx at lists.ximian.com
> Message-ID: <436677E4.6030801 at standingwave.org>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Andrew Satori wrote:
> [stuff snipped]
>
>
>> 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)
>>
>
> [stuff snipped]
>
>
>> 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
>>
>
> Ok, this probably has been hashed out before...
>
> Andy, do you (or anybody else) have an idea of how we can bend the  
> right
> peoples' ears in the Apple Dev tools group? Random users howling about
> it on mailing lists hasn't produced what we need, but somebody in the
> community probably has the connections to talk seriously with Apple's
> management...


Peter yes this is the key point. An opinion given recently was that  
Apple will listen if people start saying they can't/won't release  
software or sales drop, which is a no brainer. Unfortunately getting  
the message across seems not to be easy.

I suspect that many of the software management team at Apple are ex- 
NextStep Cocoa experts (and experts don't normally like change cos  
they cease to be experts) - many top scientists poo-poo big advances  
by lesser known scientists for this reason - we are all human!

Do you have any ideas? Perhaps the platform envangelists - there is  
one for Java:

Alan Samuel
bluker1 at apple.com
Java, Dashboard & .MacSDK Evangelist

This was taken from the Apple Java mailing list.


> Given Apple's somewhat open stance with OSS, I'd hope we could get  
> some
> help with extending XCode. I can see them not being ready to spend the
> resources to come up with a nice polished XCode SDK, but they ought to
> be willing to devote a bit of time to a few registered, NDA'd external
> people. "Here's the class dumps and a quickie writeup on how this  
> stuff
> works under the covers".
>
> -Pete


Obviously XCode being Apple's own IDE makes it top choice. But  
considering how far short of Eclipse and IDEA it is in many ways it  
would be a long road or need some serious resource expenditure. By  
refinement thinks like the colour coded bar on the RHS of the window  
which shows the position of errors and warnings, icon to click on in  
left margin to take you to superclass or subclass implementation, as  
well as the more obvious things like excellent refactoring support, etc.

Apple are much more open to outside ideas and OSS these days; so lets  
hope that applies even to MS. Personally I don't care if MS is the  
'creator' of C#/.NET/Mono - bottom line they copied Java and made an  
excellent alternative, Mono will hopefully stop MS from making it MS  
only as they would no doubt like.

The API looks bloated (again so Microsoft) - I think I read 5,000  
methods - but the basic classes that I have used are usable and easy  
to understand.

Sorry but one more point:

An awful lot of software (most?) is bespoke software written in-house  
by company developers to do specific tasks required by their employer  
(commercial companies, universities, hospitals, etc). Of course it  
goes mainly unnoticed since they don't sell the software, but rather  
use it themselves.

It is this (hidden) market where many Java and C#/.NET/Mono  
developers work, and without good support from Apple for both Java  
and C#/.NET/Mono the Mac is less likely to be considered for purchase  
in these areas.

If C#/.NET becomes the main dev environment on Windows as no doubt it  
will then having a good toolchain for such development on MacOSX can  
only really benefit Apple

e.g. employee wants a Mac, most users have PCs, company develops S/W  
package on PC, but thats cool cos the Mac can run it as well,  
employee gets a Mac rather than being forced to buy a Wintel.


Thanks,

Tim Mowlem