Re: Focusing on innovation re: mono, python et al



On Sun, 2006-07-16 at 18:57 +0200, Lluis Sanchez wrote:
> >

Hey LLuis, I very much agree with your point of view. And I thank you
again and again and again for MonoDevelop. You should be extremely proud
of your work.

As a developer who is *very* worried about memory consumption of mobile
applications like tinymail and desktop applications like Evolution (and
a few others), I will most certainly use your MonoDevelop and the Mono
virtual machine for many of my upcoming software developments.

If GNOME wants to lose software developers, it should definitely keep
rejecting innovations like .NET and Mono. By the subtile way GNOME is
currently already rejecting Mono and other higher programming environ-
ments, it will definitely lose for example me.

Most people know I'm very opinionated and working hard to get GNOME to
be much more friendly for higher programming languages and environments.

I also agree the situation *is* actually improving.



All GNOME people should understand this:

Software developers, want to work with the finest technologies available
on this earth. If GNOME glues itself to GObject and C, it will not be
used by the generation of young software developers that will come after
us.

Yet THEY will be the ones that will build compelling applications. WE
will burn out and WE will eventually stop development. FACE THIS.

I will even strongly advise them to use another development platform.
GObject and C, will not get them anywhere compared to modern other
software development infrastructures. You don't even have to face this
anymore: it's already the hard reality.

GNOME, its community, needs to understand this. If it doesn't, it will
not survive. Which would, in that case and in my opinion, be totally
fair and totally correct.


Innovate.

Like MonoDevelop. 

Thanks, LLuis. You are one of my heros for making MonoDevelop reality.


> GNOME is useless if there are no applications running on it. That's the
> key success factor. Applications.
> 
> It's not so important which applications do gnome include, since distros
> can take this decision, depending on the specific target of the distro.
> What's important for gnome is to provide a good infrastructure for
> developing and running applications.
> 
> Some of the posts in this thread have been defending the "purity" of
> GNOME, and they have been against the inclusion of Mono because it could
> lead to a bloated and memory hungry GNOME. But "purity" is an abstract
> concept, we should look at the reality. The reality shows that people
> are using everyday Mono based applications, and they are happy with
> them. The reality shows that new applications are being built with high
> level languages and frameworks like Mono and Python, not in C.
> 
> If there are memory and performance problems with Mono or Python,
> excluding them from GNOME is not a solution, because like it or not
> users will still use them to run applications. 
> 
> GNOME should adapt to this reality if it wants to survive. And adapting
> here means giving the best support it can provide to high level
> languages, like it did in the past for C.
> 
> The Mono framework overlaps in some areas the existing gnome framework,
> yes, but this problem is not specific to Mono. That's a problem you will
> have with any other high level language/framework, because the gnome
> framework is based on a C API, and some of this API do not fit well in
> higher level languages. Or maybe it could fit, but at the cost of losing
> ease of use and a better integration with the rest of the framework.
> 
> If the goal of a high level language/framework is to make it easier to
> develop applications, it can't be constrained by the underlying C api.
> If it means duplicating libraries and having for example two xml parsers
> in memory, so be it. It's still a good deal.


-- 
Philip Van Hoof, software developer at x-tend 
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
work: vanhoof at x-tend dot be 
http://www.pvanhoof.be - http://www.x-tend.be




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]