Re: Time to heat up the new module discussion

[Chipzz <chipzz ULYSSIS Org>]

On Thu, 13 Jul 2006, Ben Maurer wrote:

> > On Thu, 2006-07-13 at 02:00, Ben Maurer wrote: [...]
> > > In the long term, Mono can potentially reduce our performance problems.
> >
> > In the short term, there are performance problems and Mono will worsen
> > them.
>
> In the short term, Mono will deliver us applications many times more innovative than what we currently have. They might consume a bit more memory than what they would have if written in C. However, writing in them C would mean waiting much longer.
>
> If we can write the basic functionality faster, we have more time to spend on performance.

I think both the mono platform and the python languages are great plat-
forms. I also think they have certain usages, but with certain restric-
tions:

* Great platforms for ISV's to write applications. ISV's can specify mi-
  nimal system requirements (both in terms of memory and in terms of
  other platforms needed), and companies wishing to use those apps just
  have to adapt to those requirements (they can buy whatever hardware is
  needed, after all). We as gnome want our desktop to be usable on even
  low-end hardware, like that old pentium 2 sitting in the corner.
* Great way to *prototype* an application. I myself intend to write a
  little app, but I would not want to impose python or mono restrictions
  on possible users. Initial implementation will probably be in python,
  but after the feature-set is complete it will be ported to C. The
  point here is: the thing you want to get right first is the application
  *logic* (how it behaves, the rules for interacting with the user). For
  this purpose, languages like python and the mono platform are great.


* The core of the desktop should be in C (or possibly C++). This includes
  libraries, the panel, the core applets (like the clock, taskbar switch-
  er), nautilus (and probably some others). The user with his old pentium
  2, who just requires a basic desktop, should never have to use python
  or mono.
* Libraries should be in C no matter what. This excludes beagle for
  example. Reason for this: anything other than C pulls in extra libs,
  like libstdc++ etc, which make other language bindings a pain.


Oh, and as a totally seperate personal gripe of mine (but also an example
as of how to *not* do things): I would like the gnome-terminal dependency
on libglade to be gone again. We had a perfectly working gnome-terminal
without libglade several years ago. Then, for exactly no good reason, a
libglade dependency was introduced. The reason it was introduced was pro-
bably for (GUI) maintainability, which is totally void, as the GUI of
gnome-terminal changed exactly zilch (or very little, which would have
been easily made to the non-glade version), and as a result we have an
extra dependency, and increased loading time.
This is the exact opposite of what I would like to see happen (and have
touched upon shortly above: reducing dependencies, and prototyping in a
high-level language, following a reimplementation in a lower-level lan-
guage): we had a perfectly working code base, and the GUI part had been
static for years, still *is* static, and is most likely to be static for
the rest of its life. There was exactly nothing (or extremely little) to
be gained from this change.

kr,

Chipzz AKA
Jan Van Buggenhout
--

------------------------------------------------------------------------
                 UNIX isn't dead - It just smells funny
                           Chipzz ULYSSIS Org
------------------------------------------------------------------------
"Baldric, you wouldn't recognize a subtle plan if it painted itself pur-
 ple and danced naked on a harpsicord singing 'subtle plans are here a-
 gain'."