Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
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 i
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
Mark Constable wrote: > 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. As I understand it, these were to be nothing but OPTIONAL parts, nothing proposed so far was introducing any new mandatory dependencies. -- Rex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
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. > ... 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. 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. Especially so if the hardware is minimal which is also an increasing trend every bit as much as desktop PCs are getting more powerful. 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. --markc ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
Mauricio Piacentini wrote: > Andras Mantia wrote: >> I already stated my reasons, I don't think I should repeat them. > Just want to support Andras here Now that I've read the justifications for Andras' position, and while I respect the opinions given, I think we can only to agree to disagree (emphatically on my part) on this. It would be nothing but hypocritical on one hand to produce these bindings for other languages (in kdebindings), and then turn around and say that they're not good enough to actually use anywhere meaningful within kde (modulo issues wrt module interdependencies, but that's something that can be dealt with amicably). -- Rex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
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. Why distorted? Because everyone here is using the word "scripting language" that automatically implies somewhat condescending point of view on Python, Ruby and any similar languages. I've been professionally working with Ruby for two years now building various products that people use daily and believe me - calling Ruby (or Python) a "scripting" language is a huge mistake. They are normal MULTI-PURPOSE computer programming languages. There's more to Ruby and Python - they are modern languages, meaning that you can "code less - create more" (exactly what Trolltech's motto says). Just to give you an example, in the company I work for we have one project being developed for 2 years using Ruby. The whole application is 11k LOC of code now. On average that means that each developer produced 20 lines of code per day. Our application is not a toy, so those 20 lines of code contain some real daily work with new features and bug fixes. Can you imagine yourself doing some _real_ work in 20 lines of C++ code per day? Even using Qt-alike API's won't help you. Let's face it, there are better multipurpose languages than C++. Languages which allow you to: - write less code to do the same work and/or do your work faster - write the code people can actually understand (and not be forced to spend several years learning the programming language) - do less effort maintaining the code (both because it's easier to read it and because there's less code to maintain) There's also a fact that C++ will not gain more popularity in the next decade. I think we'll more likely have the same amount of programmers using it. Therefore it is IMHO the wise decision to invest into KDE feature now or we'll end up being the closed constant-size group of people writing some cryptic stuff nobody can understand and modify. Python and Ruby are not the only modern languages. Personally I like Scala, there're people doing cool things with Haskell and so on. Python and Ruby are the good choice now just because we have good bindings for them. Btw I should also add that it doesn't really matter which languages we'll use. It's much, much, much easier to learn Python or Ruby than C++. I learned Ruby in 1 month and started writing good code in 3 months. And I'm certainly not a superstar hacker. Most of KDE devs could do better than I. To sum up, I do think that allowing non-C++ apps with no restrictions (other than the logical ones Allen listed in his email) is nothing less than the investment to the future of KDE. Not specifying the list of allowed languages is also our investment to the future. I do believe we'll see even easier, human-friendlier languages coming. We should encourage devs using them, not prohibit. As Alan Kay says, there's no reason for programming to be this hard. PS: writing app in Ruby or Python doesn't make automatically the app slow and doesn't force it to eat and/or leak memory. In fact, my experience profiling and speeding Ruby apps tells that it's much easier to optimize your Ruby code and make it consume reasonable amount of memory than any C++ code I previously worked with. Yes, sometimes you just can't make it as fast as C++. I wouldn't write C++ parser in Ruby. But such cases are for sure special ones. PPS: if you still think C/C++ is the only true language - please reconsider. Apply for the Python or Ruby job - that definitely helps to change the POV. At least that's what happened to me during the previous two years. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Extragear tarball 4.0.3
On Saturday 29 March 2008 14:22:04 Tom Albers wrote: > Op Saturday 29 March 2008 14:18 schreef u: > > On Friday 28 March 2008 22:45:31 Tom Albers wrote: > > > Just uploaded them. Changes: > > > - kmdonkey is readded, compiles for me on hardy now > > > - kio_gopher is ported from KDE3 and will be shipped from now on. > > > > Does anyone have a list with applications shipped with the extragear > > tarball? I need to finish the announcement RSN, so it can be translated > > and all ... > > I can write something tomorrow about it. How much do you need? Just a list with applications would be fine already. Tomorrow is too late, unfortunately. I really want the announcement in the hands of the translators today (and that's me leaving in two hours) ... Sorry to be this pressing ... -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
>> If an application exists, is well written >> and respect the criteria defined previously by Allen, why not adding >> it ? It's not Cobol, nor C#, but a modern and clean object oriented >> scripting language. > > I already stated my reasons, I don't think I should repeat them. Just want to support Andras here, so that people do not get the impression that he is alone in this. I fully agree that for now, a basic, minimal KDE desktop should not depend on python or other scripting language, specially for daemons or system components in kdebase. Why? It has nothing to do with how easy it is to create the app, at least for me. C++ using Qt/KDE is frankly almost a scripting/macro language these days. But I digress: the problem is that in order to save (and this is questionable) some hours of development time for ONE developer which has a personal preference, we end up requiring MILLIONS of computers to spend additional cpu cycles, and require additional memory/resources. And I am not sure we make contribution easier: it could very well be the opposite, as most developers do not know both languages, and will not be able to help fixing/debugging them. We might even create a small rift in the community, instead of expanding it. The resource wasting part specially is not responsible imo. And we open the door for each developer writing a basic control panel module in a different scripting language, which is nuts imo for an integrated desktop environment. IMO we should try to cut dependancies for the basic desktop libraries and components, not add to them. But, I think we need to experiment instead of just discuss these issues. So here comes the diplomatic part of this email. I propose we study the potential impact of these changes using the following policy: for stand alone applications, games, plasmoids, anything else, we should strongly encourage the use of bindings and Python/JavaScript/Ruby anything else. We could maybe start with peripheral packages like our kdegames, and figure it out the issues (if any) with bindings, packaging, etc. We will be able to figure it out if there are impacts on the community aspect, and iron out the problems brought out in kcd with KDE-ification of these applications, as a first step. Who knows, maybe I am all wrong and it will open up the doors for an influx of new developers, plasmoids, apps, tools. And the community would double or triple, and no one will mind about additional dependencies. When/if this happens, we extend this policy to libs/base, with data to back it up, and no great harm done if it does not work. But for now, as we have not tried this, I am against encouraging resource wasting for a basic part of the system that has to run and be installed by default. Regards, Mauricio Piacentini ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Extragear tarball 4.0.3
Op Saturday 29 March 2008 14:18 schreef u: > On Friday 28 March 2008 22:45:31 Tom Albers wrote: > > Just uploaded them. Changes: > > - kmdonkey is readded, compiles for me on hardy now > > - kio_gopher is ported from KDE3 and will be shipped from now on. > > Does anyone have a list with applications shipped with the extragear tarball? > I need to finish the announcement RSN, so it can be translated and all ... I can write something tomorrow about it. How much do you need? Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Extragear tarball 4.0.3
On Friday 28 March 2008 22:45:31 Tom Albers wrote: > Just uploaded them. Changes: > - kmdonkey is readded, compiles for me on hardy now > - kio_gopher is ported from KDE3 and will be shipped from now on. Does anyone have a list with applications shipped with the extragear tarball? I need to finish the announcement RSN, so it can be translated and all ... -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Non-C++ Apps in KDE Main Modules (Was: Guidance in KDE Admin)
On Saturday 29 March 2008, Nicolas Ternisien wrote: > Yes, and where did you find your binary Qt 4.4 version to compile KDE > 4 ? You compile it too from SVN. Don't get silly. Qt 4.4 IS available in binary form if you want to use it: http://download.opensuse.org/repositories/KDE:/Qt44/openSUSE_10.3/ And qt-copy is in the KDE SVN repository, while the other dependencies are not. If they would be at least mirrored in kdesupport, it would be much easier. > as Aaron said, this is because > something is not widely used that it is not available everywhere. How > many CMake version every distributions packaged before KDE 4 decided > to make it its builder ? But cmake was available when KDE 4.0 got released, and we had quite some feedback from the cmake guys to fix bugs. Are you sure all those little dependencies will be available as final releases? Would you release KDE 4.1 if Qt 4.4 final is not released? Ok, I'm exaggerating, but you cannot compare what you listed with dependencies of a single application. > And why not ? Because what I said: I don't have to have running in the memory X interpreters. > It is as if you think there is an unlimited pool of > available developers, all with perfect skills in C++. Developers who > contributes to KDE come with their skills, and you seem to close the > KDE door to Python-only developer who would like to create a Clock in > Python for the KDE desktop ? They are free to creating, distributing, putting in KDE svn. What I don't want is to not have a C++ clock that is installed by default. Wasn't this clear? > He has to know C++ only to contribute to > KDE ? You are either did not understand what I wrote or deliberately misinterpret my words. > Once again, it's as if Google will always give money to KDE project > for re-implement something. It was a suggestion how we could get a C++ replacement. > If an application exists, is well written > and respect the criteria defined previously by Allen, why not adding > it ? It's not Cobol, nor C#, but a modern and clean object oriented > scripting language. I already stated my reasons, I don't think I should repeat them. Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
