Subject: Re: [gnome-love] GNOME needs some good SDK
Date: Fri, 02 Mar 2012 19:28:19 +0100
Its an interesting statement, could you give some proof of this? Do
you have some test metrics or some performance comparisons to prove
this?
On 02/03/12 19:09, Michele De Pascalis wrote:
Qt is lame. And, no, Vala doesn't give you the
performance of C at all, simply because it's a wrapper around it
(actually it's a wrapper around a wrapper around it).
Implementation layers between Vala and C decrease performance far
more than an OOP language does compared to C.
If you want to go with C++ then you would probably save a lot
of time and effort by using Qt. But then you might just as
well join the KDE-Love mailing list ;-). I have my issues with
Qt though, especially when it comes to video for desktop
applications. I would prefer a higher level language more
along the lines of Java or C# in terms of syntax. Performance
is important of course if you are going to make it the default
framework for GNOME development. That is what I like about
Vala. I get the performance of C with all of the niceties of a
higher level language.
I would use C++ if we care about performance
(and I'd care), Objective C if we don't.
Inviato da iPhone
Il giorno 01/mar/2012, alle ore 20:46, Brian Duffy
<brduffy gmail com>
ha scritto:
Hmm. When was the last time you tried it?
I have not been using it for a long time but
I have managed to do quite a lot with
Vala/Clutter and so far it has been pretty
stable. I just wish it had better debug
integration. Still, I am far from a complete
application so things may crop up. For now,
I am liking the ease and flexibility of it.
What language would you recommend for a
*standard* programming environment with
GNOME, other than C?
Vala compiles in C/GLib, that actually
provides an object sistem written in C,
using C structs to provide it, with
reflection and all. Using structs to
provide OOP is less performant than
using native OOP classes: GLib is
compiled in structs that are compiled in
assembly, while native OOP classes are
compiled in assembly without any
implementation between. Briefly, GLib
results in a system of structs to
represent a system of structs, while
native OOP implementations are just
systems of structs. There is the
difference of an implementation layer,
that is overhead. It's quite similar to
every runtime object system, like those
in Objective C, Java, Python, ecc.
Plus, compiling from C means low-level
exceptions, while compiling from a
native OOP language means high-level
exceptions.
However, I'm not so good at
explaining such complicated concepts
in English...hope you get it anyway.
Vala
is translated in C/GLib
before it's built, that
means so many data
structures in assembly,
that means overhead.
And, Vala was quite
unstable the latest time
I tried it, throwing
meaningless low level
exceptions (a good inheritance
from C).
Err... I don't really
understands this.
What are you saying
actually? There should be no
overhead in running time.
Maybe slight overhead only
at compilation time. Which
don't mean much if it means
increase in productivity and
less programmer time used.
Or, I misunderstood your
point? Care to elaborate?
Personally, after
quite a while
deciding what
language to use
for my project, I
went with Vala. I
just did not want
to deal with
writing my
application in C.
If Vala could gain
an excellent IDE
with a proper
visual debugger
that isolated you
from the
underlying C code
then I think that
would make for a
nice development
environment.
Problem is, I
don't see the
community getting
this done with
Vala. I'm just
happy that they
have done what
they have! It's
amazing really.
However, you can't
escape the fact
that many of these
contributions are
made by people
with other, more
pressing
responsibilities.
The most
successful ones
are often
sponsored by a
larger company,
but there
contributions are
sometimes limited
to that company's
needs.
My biggest
hope is for a
company like
Canonical to
spend a good
deal of time and
money and
develop a kick
ass Vala
IDE/Debugger and
API even if they
have to charge
for it.
Cocoa is
not a single
framework it
has a lot of
them, I think
even more than
gtk+ and gnome
have together.
MS also has
many
technologies,
frameworks and
solutions. So
I'm thinking
nothing is
that bad with
gnome, but
maybe a good
ide is needed
27.02.2012
23:31
пользователь
"Darton
Williams" <dartonw gmail com>
написал:
>
> On Thu,
Feb 23, 2012
at 4:38 PM,
Michele Alex
D. De Pascalis
<glaedr il drago gmail com>
wrote:
>>
>> Just
look around:
Apple and
Microsofts
have their own
SDKs, APIs and
IDEs perfectly
working with
them. Compared
to these,
developing for
GNOME is way
too hard and
complicated.
Maybe we have
the fastest
software, but
we have to
write with
Gtk, which is
just a
toolkit,
without
anything else
really
integrating
it. And C is
over, so
autogenerating
a wrapper
isn't a good
solution
(talking about
gtkmm). If a
newbie gets in
touch with
Cocoa and
Xcode, he gets
templates, he
gets wide
documentation,
he connects
events with
handlers by a
drag'n'drop,
cutting on the
IDE's editor.
>> But
it's not just
about the IDE
itself, it's
also about
paradigms:
Apple chose
Model View
Controller and
Delegation,
and everything
is written
around these,
and it takes
seconds to add
a View to your
application.
>> I'm
saying this
because I've
been learning
Cocoa for
eight months,
and I had
learnt C++
before. Even
now I know C++
is better in
many ways, but
trying back
Gtk made me
understand
it's not about
the language,
now. Those who
write iOS or
Mac apps know
what I mean
with all this.
>>
_______________________________________________
>>
gnome-love
mailing list
>> gnome-love gnome org
>> http://mail.gnome.org/mailman/listinfo/gnome-love
>
>
> I fully
agree with
this statement
- that GNOME
desperately
needs a
unified
API/SDK. It
would
accelerate
adoption of
GNOME simply
because
application
development
would become
less of an
arcane art. As
a developer, I
feel that I
could
contribute to
that effort.
>
> So how do
we get
started? :)
>
>
_______________________________________________
>
gnome-love
mailing list
> gnome-love gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-love
>
