Re: GNOME, .Net and Mono

[Sean Middleditch <elanthis awesomeplay com>]

On Sun, 2002-02-03 at 08:48, Crispin Wellington wrote:
> 
> On Sun, 2002-02-03 at 01:39, Sean Middleditch wrote: 
> > Well, I'm thinking along these lines:
> > 
> > As a wrapper, each language would only need *one* interface - the Mono
> > interface.  So instead of needing PyGTK, PyGNOME, PyBonobo, PyCORBA, and
> > whatever other ten billion, all slighty differently stylized Python
> > wrappers, there'd just be PyMono, and everything would be accessible
> > thru that.
> Does that make it yet another GTK, GNOME, Qt, Tk? Another interface.
> Theoretically you could make GTK the API, and write middleware that
> would turn the calls into Qt calls, Tk etc. So is .NET's API going to be
> *better*? What makes one API better than another? Marketing or design? 

AYe, you've got a point there.  I don't it is so much the API
differences, but more the fact that we won't have to write a wrapper for
each language.  Just let them use the Mono bindings they'll (eventually)
already have.

> 
> > For a scripting interface... well, Mono *would* be the scripting
> > interface.  You've got your itnerpreter built in, you have a huge amount
> > of support libraries, plus any exposed app functionality, and you won't
> > be limited to language.
> But I like using Python. I like using C and C++. I kinda like using perl
> ;). Im teaching myself lisp slowly and one day would like to teach
> myself postscript :-P Every language has purposes its built for. If I
> need to process large numbers of text files and match lines using
> regular expressions to gather data, then I'd use perl. If I wanted high
> speed and lowlevel control of datastructures Id use C++. 

Exactly.  That way, every program could use all those language.  Instead
of being limited in app XYZ because the authors only wrote Python
bindings, you now can use any Mono compatible language with the
application.  Perl, Python, etc. will all be eventually tied into Mono
(also look at the Parrot work, which is similar in some ways to .Net).

> 
> Will Mono just become another? Why would I stop coding in my present
> languages? What is C#? Is it really that radically different? 

Again, Mono is not C#.  Mono is .Net.  C# is just a language designed
for .Net.  Kinda like how you can use the Quake engine in a game without
using Quake itself - Quake is the game the engine was designed for, but
it's usuable in many other games as well.

> 
> > You won't need a Python itnerface, a Perl
> > interface, a Ruby interface, a C# interface, etc. for each application.
> No. Youd need a Mono interface. 

Yes.  But then just that one, single interface.  You wouldn't need to
write 10 different interfaces to make 10 different programmers happy.

> 
> > The same is true for plugins.  Every app has a different plugin
> > architecture, and most of them are *erally* ugly (requires restarting
> > the app, or doesn't expose as much functionality as the scripting do,
> > etc).
> A preset plugin architecture. Will we be emancipated by its brilliance,
> or restricted by its control? 

Well, I suppose we'll have to wait and see.  Since this is all open
source software, I doubt the control issue will be overly bad.  I don't
see how Mono would restrict it any more than any other hacked together
plugin architecture available.  

> 
> > While it won't be the perfect design (i.e. ultimate), it does seem
> > better than anything else I've seen to date.  Thus my additional comment
> > "until someone invents something better."  Which hasn't happened yet,
> > that I can tell.
> Is anything ever Ulitimate or is that like heaven for programmers? Like
> Turing Nirvana :) 

Things are ultimate so long as we think it's the best.  Then 2 minutes
later the "other guy" comes out with something better, and we go on to
that.  This is the computer world.  ~,^

> 
> > Well, if when writing a program in C, I'm forced to generate a Mono
> > call, which generates byte code that then must be interpreted, resulting
> > in an RPC, just to manipulate a window... ya, that'll suck.  *but*, if I
> > can trim out all that CORBA and Bonobo and such to use one single small
> > layer for RPC, I think it would be a lot faster.
> Security and control concern we with this RPC idea. 

I believe Mono/.Net was designed with a *lot* of security in mind.  Read
the article Miquel was in.  While I'm sure various implementations will
have bugs (what software *doesn't*?), the open source Mono will likely
be the most secure of them all.

> 
> Excuse my scepticism, but theres been some strange twists in Mono and
> Gnome over the last few weeks. What first with the Licence change for
> Mono, and now a vision of Gnome mutating into that Licence model. Will
> one day Gnome fork? 

Well, myself prefering the BSD/X11 license over the GPL, I think the
license change was great.  My love of Open Source is technical, not
ethical, so I see the GPL has a hindrance to the adoption and spread of
technology.  Most corporations see it the same way; thus, the change of
Mono's license to make it easier to use with big corporations that
don't/can't release GPL code.

As for GNOME being based on Mono, I suppose that's how you look at it. 
In the end, everything will be C code that controls the underlying
system.  Mono would tie into and wrap parts of that.  I honestly don't
see how GNOME will *change* to be Mono based; more, Mono
bindings/interfaces will just be standard with GNOME software.

But, that's how *I* see it, I guess the actual GNOME developers will
determine that for us, hmm?  ^,^


And again, if I'm way off target with any of my assumptions, please
point them out.  I don't generally enjoy being proven wrong, but I'd
rather that happen than be stuck in ignorance.  ~,^

> 
> Whatever happens, its gonna be interesting. 
> 
> Kind Regards 
> Crispin
> 
> _______________________________________________
> gnome-devel-list mailing list
> gnome-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-devel-list