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
