Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)

Aaron J. Seigo aseigo at kde.org
Sun Mar 30 01:38:52 CET 2008


On Saturday 29 March 2008, Mark Constable wrote:
> On 2008-03-30 09:12, Alexander Dymo wrote:
> > I read the whole thread today and felt a bit sad. Not because there's
> > disagreement on whether we allow python application in KDE main module or
> > now. But because both Guidance supporters and critics IMHO seem to have a
> > really distorted view on modern computer programming and modern
> > programming languages.

I agree with what you have said, Alex. I think getting concerned over the use 
of the term "scripting language" is a bit unnecessary, it's just a commonly 
used term is all. My use of it does not bely any prejudices against them as 
general purpose languages.

Now, to deal with some of the interesting misconceptions:

> The main point is that introducing these kinds of packages intermixed
> with core C++ based code pollutes that environment and demands that
> packagers and end users MUST install dependencies they may otherwise
> not need.

That's true of every single dependency we have in KDE. Hardly anybody bats an 
eye when we pull in Yet Another Library, so doing so now is really 
hypocritical.

> Qt/KDE is pure binary code with minimal interpreter dependencies 
> and I, for one, do not want to have to install perl, python, ruby, mono,
> java (yikes! that's 10Mb + 20Mb + 10Mb + 40Mb + 80Mb) and how ever many
> other scripting environemnts just to run a basic desktop system.

* Dependencies are handled for you when installing from packages, and simply 
cause items to be skipped when they are not available. So "more work" is not 
at issue.

* We're not talking about all languages: we're specifically discussing Python. 
Saying that it's a slippery slope to adding any language anywhere missed 
Allen's earlier email and completely underestimates the amount of push back 
there would be for some random language. I mean, we are having a hard time 
getting a Python app in svn, so thinking that Mono, Haskell, $whatever would 
get in is absurd.

* Disk is so amazingly innexpensive these days that being concerned over 
10-100MB of usage is a bit inane (I'll cover mobile devices below separately)

* You probably already have Python on your system, so this is probably a 
really moot point.  Perl is even more widely distributed, Java is very common 
and ruby is getting there.


> Especially so if the hardware is minimal which is also an increasing
> trend every bit as much as desktop PCs are getting more powerful.

 *  Many Linux based UMPCs come with Python on them already these days 
including the EEE PC, N800 and the OLPC.

* On devices where disk space is an issue, I really doubt you'll need things 
like a printer job viewer.
 
* For resource consumption issues, UMPC devices already use Python for 
numerous tasks, including UI (OLPC is an example). For even smaller devices, 
see above comments on disk space.

The truth of the matter is that hardware is actually growing in the mobile 
space so that we desktop people consider it now to be "minimal". Storage, 
memory and processor power is growing in all these devices, not diminishing. 
UMPC devices are fully capable of running Python apps just fine. So again, 
we're probably back to talking about really small things like phones where 
these issues may remain at the present time.

> I have no problem if these non-binary scripted apps are in an optional
> separate official area but I think it would be a mistake to intermix
> them with core C++ libs and binaries.

Of course, libraries are not a relevant part of this discussion.

Btw, all the nay sayers are some 2+ years late. We already had this whole 
discussion at Akademy in Malaga, it was a very very well attended session and 
the conclusion was to bring Python/Ruby apps into KDE modules. I think it is 
useful to have this discussion so as to work through issues and find 
consensus with those who missed out the first time this was decided, but 
really ... it's already been decided, unless someone can bring up a really 
compelling reason to overturn it. That hasn't happened at this point.

The benefits, as outlined by Alex, Jonathan, Rex and others are immense. We 
would be absolutely daft not to take advantage of progress in languages.

Btw, at one of this year's Trolltech DevDays in a general session (so everyone 
was there) it was asked from the stage how many developers there were 
interested in various non-C++ languguages. Of the ~500 ppl there (iirc?) a 
few dozen raised their hand for python, a handful for java and (again iirc) 
exactly one for C#. This was at a very heavily C++ oriented event, of course, 
but it shows that the Java/C#/etc spectre is pretty much non-existent. 
There's very much a trend towards just a couple of these new languages; and 
historically, popular language proliferation has never happened: there's 
always been a few dominant languages.

Right now Python and Ruby, at least in the Open Source world, are the two 
rising stars. C++ is not likely to wane soon, but the growth is in 
Python/Ruby. The benefits to productivity, and ultimately quality, are 
impressive.

Now, where this could get tricky is that we need to continue attracting C++ 
devs and keep them excercising their C++ muscles too. Otherwise we'll have a 
slightly difficult time maintaining our libraries, let alone all our great 
C++ apps ;) So while we should open the doors for Python/Ruby, imho, it will 
also be important to keep the C++ drums thumping as well.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20080329/98c172c8/attachment.pgp 


More information about the release-team mailing list