Re: 3.2: gjs/seed

On Fri, 2011-04-29 at 09:00 +0200, Johannes Schmid wrote:
> Hi!
> Am Donnerstag, den 28.04.2011, 18:38 -0400 schrieb Colin Walters:
> > On Wed, Apr 20, 2011 at 7:12 PM, Colin Walters <walters verbum org> wrote:
> > >
> > > == Dynamic Languages in GNOME ==
> > >
> > > One thing that's worth addressing though (again) is the question "do
> > > we need both Python and JavaScript?".  The uptake of both seed and gjs
> > > has been relatively low; lower than Python at least for scripting
> > > GNOME apps.  However, I think at least one the core reason for working
> > > on JavaScript remains that *we define the platform*.
> I think the "we define the platform" argument is really weak. Our whole
> platform is written in C and we definitly don't define that platform.
> You can include a lot of really old Unix API in C and nobody can prevent
> you doing it. Sting handling is more or less completely broken in C and
> still GString is only used in a few cases.
> C++ has it's own implementation of containers and hash-tables which we
> don't control either. Same for Python, same for more or less any
> language despite probably Vala where we really control the language in
> some ways. Still even Vala maps all kind of old-style Unix APIs.

String handling and containers are sort of limited lowlevel things
though. I don't think anyone has a problem with using the language
native versions of these. Especially since the gnome platform story on
these are quite weak.

However, a platform like pyton is much richer. It contains many things
that directly conflicts with our platform. Config APIs (gsettings), http
support (soup), file handling and streams (gio), ssl support
(glib-networking), etc. Isn't there even talk about a native python
widget toolkit?

The problem is, once you start writing in python it becomes natural to
use these modules, and they inherently pull in other modules, until
eventually you're not using much of the gnome platform, and get into
problems interacting with the gnome side of your code (no giostreams, no
gcancellable, etc).

This is not insurmountable, if you take care, but in the js side you
have none of these issues. Everything will naturally use the gnome
platform stack, since there is little else (apart from core language

That said, I'm not sure we should be writing large apps from scratch in
plain JS. I'm personally much more into the "app core in C, ui logic in
js" camp.

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