Re: GNOME needs some good SDK

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.

2012/3/2 Brian Duffy <[email protected]>

> 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.
>
> Brian
>
>
> On Fri, Mar 2, 2012 at 8:45 AM, Michele De Pascalis <
> [email protected]> wrote:
>
>> 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 <[email protected]>
>> 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?
>>
>> 2012/3/1 Michele De Pascalis <[email protected]>
>>
>>> 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.
>>>
>>>
>>> 2012/2/29 Arief M Utama <[email protected]>
>>>
>>>>
>>>> On 2/29/2012 8:05 PM, Michele De Pascalis wrote:
>>>>
>>>> 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?
>>>>
>>>> All the best.
>>>> -arief
>>>>
>>>>
>>>>
>>>>  2012/2/27 Brian Duffy <[email protected]>
>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>>  2012/2/27 Konstantin Evdokimenko <[email protected]>
>>>>>
>>>>>> 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 <27.02.2012%2023>:31 пользователь "Darton Williams" <
>>>>>> [email protected]> написал:
>>>>>>
>>>>>> >
>>>>>> > On Thu, Feb 23, 2012 at 4:38 PM, Michele Alex D. De Pascalis <
>>>>>> [email protected]> 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
>>>>>> >> [email protected]
>>>>>> >> 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
>>>>>> > [email protected]
>>>>>> > http://mail.gnome.org/mailman/listinfo/gnome-love
>>>>>> >
>>>>>>
>>>>>> _______________________________________________
>>>>>> gnome-love mailing list
>>>>>> [email protected]
>>>>>> http://mail.gnome.org/mailman/listinfo/gnome-love
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>   --
>>>>> Duff
>>>>>
>>>>> _______________________________________________
>>>>> gnome-love mailing list
>>>>> [email protected]
>>>>> http://mail.gnome.org/mailman/listinfo/gnome-love
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> gnome-love mailing [email protected]://mail.gnome.org/mailman/listinfo/gnome-love
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> gnome-love mailing list
>>>> [email protected]
>>>> http://mail.gnome.org/mailman/listinfo/gnome-love
>>>>
>>>>
>>>
>>> _______________________________________________
>>> gnome-love mailing list
>>> [email protected]
>>> http://mail.gnome.org/mailman/listinfo/gnome-love
>>>
>>>
>>
>>
>> --
>> Duff
>>
>>
>
>
> --
> Duff
>

_______________________________________________
gnome-love mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gnome-love