Gnome bindings discussions

The set of .Net languages != The set of all languages that Open Source programmers would like to use.

Yes, this is absolutely true. Unfortunately the MS stench on .Net generally prevents people who are supposed to be technically competent from seeing the real benefit to the underlying technology.

This resistence to good sense is what will continue to keep OSS development in the dark ages.

The set of .Net languages != The set of all languages that Open Source programmers would like to use.

That's about the size of it, yes. A .Net version of Python or PERL is never going to be Python or PERL.

Despite GObject, C does not have object-oriented design built in like C# and Java do and this requires all kinds of horseplay to get the GObject C code to fit in the peg hole of a true object-oriented language like Java or C#.

It gets even more interesting when you need to return meaningful errors.

You can't just decide on a higher level language or environment for Gnome like Python, or Mono, because it would only be useful if you could write the whole desktop environment in it. You can't.

I don't follow your logic here. They would be perfectly useful if you could write apps in Mono/C# or python. And significant numbers of useful Gnome apps are written in those languages. The discussion was not about whether to rewrite the Gnome libraries/framework in a non-C language.

I would imagine that something like Ruby would get used for desktop level VB equivalent types of applications, and also for writing applets that would plug into underlying infrastructure.

Yes, and C# where you wanted a language that was easier to develop in and faster than Ruby although still not as fast as the language that the underlying libs were written in (C for Gnome and C++ for KDE).

but what's the point in picking something higher level like C# with Mono when you have to write the core stuff in C anyway - and then wrap it - and then make sure it isn't error prone

It's easier to write code in C# than it is in C, and some would argue that it's easier to write in C# than Qt/C++.

It just creates even more work? The same goes for Python as well really.

Well if people such as myself or the Gnome bindings developers can develop and support the stuff I wouldn't worry about whether or not they find it a lot of work.

Plus, I just don't like all this language neutrality rubbish in .Net. People have largely accepted this in the wider .Net world because VB developers have realised the differences between VB.Net and C# are pointless.

I'm interested to find out whether that's a good idea or not by implementing the C# Qyoto/Kimono bindings for Qt/KDE - I would rather try a practical experiment than engage in flame wars. Certainly it's worth doing just for C#, and if people have fun with Iron Python/Nermerle etc and write useful apps, then that will be a bonus.

I don't follow your logic here. They would be perfectly useful if you could write apps in Mono/C# or python. And significant numbers of useful Gnome apps are written in those languages. The discussion was not about whether to rewrite the Gnome libraries/framework in a non-C language.

Hmmmm. The problem is that the core desktop environment infrastructure has to be written natively in something. The point was that Gnome's, and other desktop environments', problem is that they need an easier and more straightforward way of doing this - not just that they need a higher level desktop language. KDE has C++ and Qt. Gnome basically doesn't have anything, and it isn't going to be made any easier by wrapping that with Mono or Python. That's the problem that is being missed.

Yes, and C# where you wanted a language that was easier to develop in and faster than Ruby

In the KDE world I'd imagine you'd use C++ and Qt for this. There's not really much room for an intermediate, nor for a couple of different runtimes.

Well if people such as myself or the Gnome bindings developers can develop and support the stuff I wouldn't worry about whether or not they find it a lot of work.

If you can wrap the code nicely and create one to one, or as close as possible, bindings as possible and your underlying code is nicely organised then yes. However, if you've ever seen a Mono application silently fail because a piece of C code underneath has failed, or the CLR craps back a nice pointless error at you, you'll know what I mean. It happens quite a bit with .Net and Win32 as well. This is where the work kicks in, as it has for Microsoft.

I'm interested to find out whether that's a good idea or not by implementing the C# Qyoto/Kimono bindings for Qt/KDE - I would rather try a practical experiment than engage in flame wars.

This ain't a flame war. This has been debated endlessly in the .Net world, especially amongst VB developers who now see little point in their new found language VB.Net. Logically, this is the case as well. Whatever language you use, if it's a .Net language then it maps on to all the same concepts and it produces the same code in the end. You may get somewhat higher abstractions where you apparently write less code, as you do in something like Boo or Nemerle, bit in the end they are cosmetic because there's no reason in the world they can't be trivially added to C#.

You can not compare apples with pears, as we say here in austria. You can compare Ruby with Python, C# with Java, C++ with Objective C. These languages have different use cases. You use Ruby and Python when there is no need for high performance. When there is a bigger need for performance you use Java/C# and if its even bigger C++/Obj.C. You use Python/Ruby when it is important to deliver a product very fast -> RAD. Python/Ruby are excelent as extensions/plugins (OOo, Amarok, KOffice, Blender, ...).

Ergo, there is need for ruby/python and java/c# bindings. Every language has its use case. You could argue what language is better only between python ruby, java c# etc. But I think KDE should not choose only one in that pairings, it should let the developer decide what to use.

i totally agree with you post panzi...

but i was targetting a specific area, name core kde.

the same hold true for the GNOME discussion, its not about making some bindings so some ppl can use them for some purpose. no, its about letting (some of) your core depend on it, and therefore it becomes a core dependency and all apps the already depend on the core then can depend on it.

important is then that its very stable/ well maintained. if trolltech delivers the bindings we can be quite shure they're well maintained (on all platforms) without costing us a lot of efford.

concerning your point on comparing different types of fruits:
i think it important that we compare them any way, and im especially interested how much slower (startup time, running speed, mem usage) a qt app in java compiled to native code with gcj will be compared to a qt app in c++.

speaking of which: didn't trolltech promis qt-java bindings for Q1 of this year?