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]http://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
