On Wednesday, 2009-12-09, Draciron Smith wrote: > Actually it's the love of C++ for application level programming that > is really limiting the growth of Linux. Actually outside of KDE there is very little love for C++ on Linux, a lot of developers prefer C, especially when it comes to low level stuff. (With a few notable exceptions like Inkscape, etc) Probably a left over from the days where C++ wasn't really that easy to write in a portable manner. I'd say it is actually a lot less common than e.g. on Windows. Basically every application by one of the big software vendors, including Microsoft, is written in C++. However I think you have a point regarding Mac OSX. It seems to be a Objective C stronghold. When I started to work on Linux, I had done mostly Java programming on Windows (and Pascal and Basic on DOS before that). Interestingly Linux is the only platform I've worked on so far that seemed to have compilers and interpreters for all languages, additionally to already quite powerful programable shell systems (when compared to DOS/Windows Batch system). I guess the difference leading to your point of view is the focus on certain languages. While Basic and Pascal (Delphi) are the strong ones on Windows, it is be Python/Ruby/Perl on Unix/Linux. If you are looking for things written in Basic or Pascal on Linux you might come to the wrong conclusion that only C/C++ is being used. Much like if you would look for things written in Python or Perl on Windows you'd come to a similar conclusion. > Me I say build it and they will come. When they do, it'll leave the > more advanced programmers free to work on more advanced topics. We all > benefit and we gain not only more apps but the load of FOSS proramming > is shared out among a greater group of people. Think about how many > times you've heard a comment like this one about wanting to help but > not being a programmer. Most of these "non" programmers could have > code up in running in a month or two in something like Gambas. That's > the whole point of the visual languages. To concentrate on program > logic and flow and minimize syntax. If just 1 in 100 got serious > about it and mastered these languages that's tens of thousands helping > expand the boundries and capabilities for all of us. Exactly. Which is why development tools/frameworks such as Gambas exist. There is also RealBasic which can be used to create applications running on Windows and Mac OSX as well. However, Basic frameworks seem to have more followers from the group of people already using Basic. Nowadays beginners seem to prefer Python. > >> In practice, that singular entity rarely dismisses a modification > >> entirely, but does exert monopoly control. > > It is common to fork a project when such "control" conflicts with a > large group of people's wishes. Sometimes the forked version dies off, > sometimes the two merge back and sometimes the origional branch dies. > Sometimes both keep on going and morph into very different > applications. Happens all the time and I see a fork coming in KDE. > There is enough revulsion for KDE 4 in the hard core KDE base too > warrant a fork. Whether the fork can attract enough coders to keep it > viable will be the question. Another question is which way existing > KDE developers will go. Not all of them can be happy with this > abomination called KDE 4. Starting to make XFCE look good. I've yet to see any developer even considering a fork. So far such suggestions seem to come from bloggers and journalists with insufficient insight into the task at hand. Some of them even suggested stuff like forking KDE 3 era code and porting it to Qt4, ignoring the man-years of work that it took the code base maintainers to do that. So one could for at a stage where all the porting has happend already, something like 4.0 release stage. But why would anyone throw away all the things done between then and now? So if one forks the state of trunk now, why would any exisiting developers work on whatever they are working right now just in a different repository? I think we can be pretty sure they are not likely to work on a different area of the code base because they could to that right now as well. Actually an interesting fact about those fork suggestions is that they come from the context of people being unsatisfied with the Plasma desktop. Interestingly none of those fork suggestors seems to consider forking just KDesktop+Kicker. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
Attachment:
signature.asc
Description: This is a digitally signed message part.
___________________________________________________ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
