The aim of the Kimono project on KDE is to write a complete wrapper for KDE/Qt using the Mono framework and is based on early work by KDE bindings hacker Richard Dale. Kimono uses KaXul, a fully XML-based representation of the UI, the Dot reports. However, the changes made to KDE in preparation for Kimono has left the other binding effort, Qt#, orphaned with a dead dependancy: QtC.Marcus Urban from the rival Qt# project spoke of ‘sabotage‘ and later communicated with us regarding the issue:
This is probably going to turn into a long history of events. Basically, Adam Treat started Qt# a couple of years ago, and Nick and I joined him on the project. Qt# depends on Richard Dale’s QtC to call C++. (If we had something equivalent to MS Managed Extensions for C++ this extra layer could be integrated into Qt# more easily. It would require a tool capable of compiling C++ and emitting both CIL and native code.)
QtC is produced by KDE’s Kalyptus tool. However, the resulting C code was not compilable and required substantial hand-editing. We also had some problems because QtC was not completely in sync with Qt#. We tried to contact Richard at some point, but he disappeared from the internet for several months. So we felt like we (Qt#) were on own our as far as a C glue library. So we began to investigate alternatives to QtC.
One of the alternatives was simply to generate our own C library with more customized functionality, but produced by our own tools so that Qt# and the C glue library would be in sync with each other. Another alternative we investigated was Ashley Winters’ SMOKE library. However, SMOKE seemed best suited to scripting languages were high performance was not a priority. Also, I could not find any documentation on SMOKE. I heard that Ashley’s new Perl Qt bindings would use SMOKE, but I do not know enough Perl for that to be helpful. In other words, looking at Perl bindings that used Smoke would be be helpful.
When Adam was still working on Qt#, Adam, and I tried collaborating with Ashley, but those efforts were largely unsuccessful. After a few IRC chat sessions and email exchanges, it became clear that we had different views on
things.
A little over a year ago, Adam stopped actively working on Qt#, and I tried to work on it myself. Unfortunately, I was very overwhelmed because we were in the middle of moving to an entirely new codebase at the time. It was not just an issue of people-hours, but I lost the only person who I could really talk to about Qt# on the very technical level. Emotionally, it left me very discouraged, so I did not release a version of Qt# for about a year.
Around this time, Richard Dale announced that he was seriously working on another C# binding for Qt using SMOKE and remoting classes. Previously, he had posted some musings about this on kdebindings list, but that was all. Then he announced his intentions to remove QtC from kdebindings. I said that in the future that would be fine because I was working on something to replace it. However, I was not expecting that he would remove QtC immediately, as he did. He also complained that compatibility with Qt# prevented him from updating QtC, but he never contacted me to advise me of this.
— Marcus Urban
Update: Adam Treat, the creator of Qt# replied to the issue in our commenting section.
Update2 : In our comment’s section we had some people saying that this is April’s fools news, but these claims are false. OSNews does not follow this tradition in general. The above reply from Marcus is real.
Maybe I’lla ctually learn C#
Crrently I’m busy with PyWt/PyKDE.
No, seriously, don’t mod him down. He’s right. Kimono and KaXul exist, but the dot story is taking some liberties with the truth.
KaXul is not a replacement for the existing XML UI mechanism. Rather, it is a set of tools for generating KDE UIs from XUL descriptions.
As for Qt#, I have to say that I think Kimono is a better approach, because it uses libSMOKE while Qt# is layered on top of the Qt C bindings.
I am Adam Treat the creator and principle developer of the Qt# bindings. There was no sabotage. Marcus is overly sensitive at times.
Richard Dale is one of the original KDE binding authors and responsible for the Qt Java bindings as well as Objective-C, QtC, and KDEC. He is also working on the Ruby bindings, the new Smoke library and the new proxy/smoke based C# bindings. He is doing great work and I look forward to seeing this progression.
Richard and I have talked and he is planning on using the bulk of the current Qt# bindings where applicable.
To clarify. Kimono and KaXul are *real* projects. The ‘central focus of 3.3’ and ‘kimono requires migrating to kaxul’ is the april fool’s part.
OK, that’s my thought too
The newsitem is now changed too.
Why would this be suprising given the fact that Ximan/Novell, the creators of MONO, is dropping support of Red Hat/Fedora (which is primarily GNOME) to go with SUSE (which is primarily KDE). See the article http://osnews.com/comment.php?news_id=6542
They are not. When I read the link below I did not come to that conclusion.
http://lists.ximian.com/archives/public/xd-testers/2004-March/00022…
It would be surprising because KDE isn’t run by Novell. Indeed, KDE doesn’t have any formal leadership. Decisions are made by a concensus of developers, with priority given to the most-profilic/oldest contributers. Thus, a decision to officially refocus on Mono would have made a lot more noise than in the mailing lists and KDE news sites.
…from Adam Treat: http://www.kdedevelopers.org/node/view/400
I have been using c# a bunch for my job, and based on my experience: if you are learning pyKDE stick to it.
To me the main draw of c# is using system.forms (writing managed c++ sucks). qt is already a really good widget set so going to c# does not have nearly the gains on a linux platform compared to on a widows platform. python IMHO is a better language than c#, but c# is easier to learn if you have c++ experience. So if you have already learned python you might as well stick with it.
With regards to Python vs. C#, would theorz recommend writing large programs, eg >300K lines in Python over C#?
Writing large programs over 300 000 lines in Python, is really asking for it. Python is great for scripts and small projects where speed and system resource priority are low.
But for large projects, you are better off with a language designed for such. At 300 000 lines of code, Python will be awfully slow and resource avaricious. I don’t advice it. Well, except you don’t give a damn about responsiveness, cpu cycles, and RAM.
As a person of many years, a freshman in college, I’m sure you’re speaking from personal experience. You’ve probably written dozens if not hundreds of 300,000+ LOC programs in various languages. Sorry to hear that your Python ones weren’t very efficient.
“We pretty much got things right with 3.2, so it’s time to shake things up a bit,” said KDE project leader Matthias Ettrich, “Exploring new frameworks will help shake the KDE developers out of a rut, and lead to lots of new ideas.”
So the guy works at Trolltech (the company that owns Qt) and is promoting a framework (.Net/Mono) with is a direct concorrent of their own product?
This has to be an April 1st joke.
Well, I’m working on a Python project that’s about 50000 lines of code, and see no slowdowns at all. It runs well and it is still easy to change even very fundamental stuff deep down due to the fact that Python is so dynamic.
That’s really not true, as Python and Ruby work quite well for large projects. Like all things, it mostly depends on the discipline of the coders, not the language. And once Parrot is out, any real advantages in speed will be nominal at best.
Heck, right now one could likely see a great boost in speed of one’s Python programs using a JIT Python compiler such as Pysco. There are cases where python is faster then C code, take this mailing list post (first hit for ‘JIT python’):
http://biopython.org/pipermail/biopython/2003-January/001160.html
Again, this could mostly be chalked up to a coder’s technique, but you can not just ignore the fact that people can and do write poor code in any language.
Taking this further, I’ll assume you mean C is a better choice for speed and resources. Imagine a 300k line program in C. You have a pointer that goes off by one somewhere, causing a overrun on only certain occasions. Problem is about 2000 functions call on this method, and nothing bothers to check it each and every time (or worse, the checks are off by one or allow overruns themselves ^^; ). Where is the bug? This is a real problem, and it happens all the time, because as C programs grow in size, they grow exponentially in complexity and become more and more difficult to read, or spend their time doing checks on each bit of data tossed around which negates the advantage of having C be ‘faster.’ Not that C doesn’t have it’s uses and places, but while Ruby, Python, and Perl doesn’t fit everywhere, C and other performance languages don’t either.
I’m not saying it is impossible to write large programs in Python(I wouldn’t consider a 50000 line project a large one). Just as I will never claim it is impossible to write an email client in Bash. The question is, will I recommend it? My response is, no with reasons which I presented above.
Besides, it doesn’t matter what I recommend, do as you wish. If it pleases you, write your CAD application in Perl.
I don’t actually believe you are insinuating that Python is faster than C. And link you provided doesn’t say much either (no source code?). Anyway, I my own benchmarks, and I don’t need a 50000 or 300000 line of code to counter your claims regarding Pythons performance and resource usage.
Do the following simple exercise
Python code:
index = 0
while index < 1000000:
<tab space>print “Right tool for the right job.”
<tab space>index = index + 1
C code:
#include <stdio.h>
int main ()
{
int index = 0;
while (index < 1000000)
{
printf (“Right tool for the right job
“);
++index;
}
return (0);
}
Name the python source “test.py” and the C source test.c. Compile the C source using you favorite compiler. Run both code and time them. You be the judge. Oh, and well your code is running, also monitor your CPU usage as well a RAM.
Now that is barely 15 lines of primitive, non complex, rudimentary code. How well do you think either languages will scale to 300000 lines of code and above?
Again, use what you will, but I’m certainly not going to use Python for anything above a couple of thousand lines of code. That just me.
uh, why did you put printf() inside the loop? you want to make the video card have an impact on your benchmarking?
Sure, let’s benchmark. But let’s try a Ruby example, instead.
echo “10000.times { puts ‘Right tool for the job.’ }” > test.rb
ruby test.rb
c:
Average CPU usage: 30%
Virt memory usage ~1.2k
Shared ~1.2k
real 0m26.886s
user 0m3.250s
sys 0m4.523s
Ruby:
Average CPU usage: 45%
Virt memory usage ~2.8k
Shared ~2.1k
real 0m35.217s
user 0m9.421s
sys 0m4.704s
So the C code is almost non-existant in memory, while the Ruby code is ~700 bytes. We see a small CPU bump. Time is up a bit. Fine. How long did it take me to code my example? How much more readable is my example compared to the ungodly mess that was the C example? How well with that scale?
C is great for kernels. It’s wonderful for embedded programs or userspace stuff where dependancies and speed need to be sparce. It works great when you need to target a large number of other langages for libraries and such (at least for now). Anything else and it is outclassed, IMHO.
Does Kdevelop supports C#,Qt# or Mono????
Fascinating! Can I have your hardware specs? Because on this machine, the c code run in less than a second. While the python code runs for over a minute. Also, the the loop is supposed to run a million times. Apparently your Ruby code just prints ten thousand lines of a string to a file.
Finally, there is a difference when a running code through a loop and when printing strings to a file. You should know that. So your experiment is not fair and objective.
Oh, I don’t know how this turned into a Ruby Vs C zealotry fest. The question was whether I would recommend Python over C# for large projects. How on earth does Ruby and C get into the fray?
Well, if you’ll forgive me messing up when copying the number into my comment from my terminal, I’ll forgive the newline in your comment which would have made your C version run instantaniously had I not fixed it. Try the code with the correct number in Ruby and you will see I just mistyped it into the comment.
Test machine was a Athlon XP 2200+ running in power-saving mode at 1060 mhz. Ruby 1.8.1, gcc 3.3.2.
And I’ll point out it was your example, not mine. So if you would like to make a more “objective” one, feel free.
And I’ll point out it was your example, not mine. So if you would like to make a more “objective” one, feel free.
Have a look at my example, and your example, do they look similar? I see a loop construct in my examples, I see none in yours. Or, perhaps, I need glasses.
No need for glasses, programming in C *ONLY* has that effect on people.
10000.times { … } does what’s inside the block 10000 times, as it says. I think that qualifies as a loop construct, don’t you?
From why own personal experience, python scales fairly well, while at the same time retaining a very high level of maintainability.
As to performance issues, I don’t think one (1) loop, with C-style coding, is a proper benchmark. Python has the disadvantage (when it comes to performances) of being an interpreted language. In most (if not every) interpreted language, loops are slow. That’s why in python there is a function called map() to avoid using loops when unnecessary…
What I mean is: when comparing languages, please compare code written in proper python with code written in proper C. It reminds me of the recent language benchmark (3 months ago?) on osnews, where some examples were simply C-transcripts.
Vague statements about big programs being slow, followed by for loop benchmarks really suggest that whilst “root” may claim to be r00t, he/she certainly seems to be 133t rather than one of the elite.
I don’t see any improper use of Python in the code I presented. How that is more C-ish that Python-ish is above me. Besides, I was trying to prove a point to the fellow who claims Python is faster than C. I think the whole argument is silly to begin with.
It’s not worth it arguing with anyone who is impevious to reality. Heck even Python is slower than semi-interpreted Java. Now to claim Python is faster than C is nothing short of incredible to me.
And even the mini experiment I presented isn’t enough to disprove that error. So if that can’t, nothing will. For all I care, you can write your Kernel in Ruby.
Thanks for the compliment, Sherlock. Oh, and I used a “while” loop, not a “for” loop , Prof.
I have written a lot of code in both Python and C and must say each has its merits. Its upto the programmer to not only choose the language and tools but also to use it wisely.
I get a kick out of all those people’s comments about how crappy ‘C’ is to program with. In case it has not been obvious both Python and Ruby (and many others) are themselves written in ‘C’. You may not be programming with pointers but your objects are converted and handled that way.
A good programmer will always manage to find the best language for the project and write good code. A bad programmer will try to find excuses by blaming the programming language he/she chose in the first place.
-Dino
That’s a bit excessive for almost anything one would do in Python. As an example, doing a ‘wc -l *.py’ (line count) on the python lib/ directory (not including the special stuff in the subdirs) totals 76,264 lines.
I wrote a file manager (of sorts) in PyObjC on the Mac that was no more than 1200 lines, using python built-ins and functions (and Cocoa/ObjC requires a lot of dumb things to set up windows and widgets).
The middle of the road solution seems to be the best: widgets and other speed-intensive things are written in C, but most of the programmer logic is in Python (or Ruby, C#/.NET/Mono, etc), and doing so leaves you with programs that are written and tested much faster than you would in C, with only small drawbacks in speed for some things (usually not noticeable on most machines)
YMMV.
Python’s performance can become a problem, but it really depends on how speed-intensive your program is. Zope, for example, is coded in Python but doesn’t have huge performance issues. You have to remember that a lot of the libraries Python coders use are written in C, so depending on what your code looks like, performance can be quite good. For many GUI apps, I would absolutely recommend Python. Take the Eric 3 Python IDE. Its written entirely in PyQt, but you can’t notice that its any slower than a Qt app written in C++.
I really don’t see language performance as a major problem for large application development. Sure you could code in python like it is a scripting language, but you can produce bad code in any language. Python is not is scripting language, it is an interpreted language that happens to support some features common in scripting languages.
I see the important area in creating a large app is design. You need a good upfront design. If your design sucks then every thing will be slow no matter what language you choose. If your design sucks then everything will be hard to maintain no matter what language you choose.
For areas of the app that you have identified as bottlenecks (and already addressed as much as possible in design), sure use c, or asm, or whatever. But it makes no sense to waste time doing the entire app in low-level languages.
As for python vs c# when it comes to scaling: I do think that c# has an advantage in that many c# developers were former c++ developers so they will be more experienced in design. But if two equally skilled team are working in c# and python respectively, I think both applications will scale just fine.
My preference for python over c# comes from the fact that I think python syntax is nicer. c# was designed to lessen the learning curve for c++/java developers and as such has inherited some of the less than optimal characteristics of c++/java.
ps. I am started learning ruby and so far is seems even better than python
For all I care, you can write your Kernel in Ruby.
Can Ruby do the ASM stuff? Ruby is very nice, but kind of little slow, non-thread safe and etc. Those issues should be fix in 2.0 as in goal.
> Zope, for example, is coded in Python but doesn’t have huge
> performance issues.
Zope *does* have serious performance issues. The only way to get zope reasonably fast is to put a huge squid cache in front of it. Most people do not notice this because they have some small sites that generate less than one hit per second.
But php or asp.net will have orders of magnitude better performance.
It’s now titled “[April Fools’ Day]” for all those including Eugenia who didn’t get it yet. 🙂
The kimono story was NOT 100% false. I quoted on my article the part that’s real. And the rest I included IS real. As I said, we don’t do april fool’s stories on osnews.
> The kimono story was NOT 100% false.
An April Fools joke is the better on the more true roots it bases.
Just to be clear, everything I mentioned exists but mono does not figure in the plans for 3.3. We may ship the C# bindings if they are sufficiently complete though.