Busting KDevelop myths

For every KDevelop release, announcements are made by various people on various news sites, and there's plenty of comments. Depending on the news site, those comments are more or less accurate, but generally, comments on KDE applications outside of the "KDE world" (planet, developer blogs, ...) are often alarmingly mis-informed and are spreading a lot of FUD. I'm sure most projects have similar issues, but I feel it's especially bad for KDE, and for KDevelop in particular. I have no idea why, but I'd like to collect and clarify a few common misunderstandings and wrong things said about KDevelop.

First of all: KDevelop 3

KDevelop 3 is not KDevelop 4. Please, if you have used KDevelop 3 and you think that makes you know anything about KDevelop 4: forget it. The two applications have nothing to do with each other. And by nothing, I mean nothing. They have a totally different philosophy and a totally different code base, and they mostly have been developed by different people.

About KDevelop's philosophy

The way KDevelop 4 works differs from the way many other IDEs work, which means some people are sometimes confused about how it works and why. But, if we wanted it to work like something that alreay exists, there would be little point in creating it. So, here's some bullet points of things people often seem to get misunderstand:

• KDevelop 4 is not a programming tutorial
  • KDevelop 4 is designed for people who know how to program, and who know how to use their tools. For example, KDevelop 4 supports building projects with CMake -- which does not mean it will magically create or maintain CMakeLists.txt files for you. It means we have tools to help you do it, such as CMake code completion and assistants to add new files. Of course, you can use KDevelop as a beginner -- I personally think it's an excellent choice -- but it's not an IDE that will save you from understanding how building an application works. Which we think is a good thing. In KDevelop, for all UI elements that have to do with things like building and debugging, or VCS support, it's very easy to tell how you'd do the same thing in the shell. It's just more convenient to have a button or a keyboard shortcut to do it.
  • KDevelop's aim is not to create an application which makes it as easy as possible to compile "Hello World" programs (although it happens to be pretty easy with the application templates).
• KDevelop 4 does not aim to be a collection of wrappers around as many tools as possible. We try to integrate existing tools instead of wrapping around them, and we try to keep everything fully transparent to the user by design. For example, although we have git support, we expect people using it to know how git works.
• We try to be as non-invasive and transparent as possible. Especially, we have no project files (well, we have, but it only contains your project name and a few similar settings -- it's not something you want to have in your project repository, it's more like a personal settings file). We have no workbench, i.e. importing a project into kdevelop is as easy as "open this directory in KDevelop" and clicking "yes use git support". You're not really "importing a project", you're just opening a directory. The only thing which brands this directory as being a KDevelop project is the project.kdev4 file, which, as said above, is just some convenient meta-data.
• The main focus of KDevelop 4 is language support. The main focus of the IDE is things like code completion, syntax highlighting, marking syntactic and semantic errors, finding information about objects in the code (type of variables, ...) and quickly navigating in your code. This is what most time is spent on in development, and what -- in my personal opinion -- makes KDevelop really more useful than a text editor plus a few GUI tools for debugging and stuff. Yes, we have things like unit test integration, debugger support, tools to edit your build configuration cache etc, but the heart piece of the IDE is the language support part. I think the eclipse people would tell you something different about their IDE.
• KDevelop is not a compiler and not a build system, nor does it contain either.

Comments frequently encountered and why they're pointless

"kdevelop 3 was good, but kdevelop 4 has none of the features"

• KDevelop 3 did lots of stuff, but it did little things really well. While KDevelop 3 supported almost every language and build system, for many of them it is questionable what benefits it provided over just using, say, kate. In KDevelop 4, this is different; we just do a few things, but we try to do them really well. If what you need is not among the things we do, then that is unfortunate, but I'm sure it's better to provide a really good tool to a few users than a mediocre tool which everyone could use, but nobody actually does use because there is better, more specialized alternatives.
• KDevelop 3 focused on being a wrapper around dozens of development tools, quite the opposite of what KDevelop 4 does. If you're looking for wrappers around tools which are difficult to use by themselves, maybe you should instead look for better tools (such as CMake over automake).
• If you're looking for complete GUI wrappers (as opposed to helpers) around tools which already have a nice interface, KDevelop 4 probably is not for you (e.g. CMake). As said above, we expect users to understand the tools we support.

"kdevelop is slow"

It's not. Seriously, it's not. I'm not going to do an excessive benchmark now, because "slow" is so ill-defined, but KDevelop 4 is by far the most responsive and slim IDE I know.
A little less subjectively, here's some numbers I took on my Arch Linux x64 (04/2013), SATA2 SSD, Intel Core i5 540M 2.4GHz CPU, 4GB RAM system (all numbers are after the respective appliction has been started before, because I'm too lazy to reboot twenty times):

RAM usage (RES):
All applications with the KDevelop repository loaded as a project, after a fresh startup.
KDevelop: around 250 MB
Eclipse: around 400MB (Eclipse does not appear to hold a parsed representation of the project's source code, at least I've never seen it parse it?! I don't know...)
Netbeans: about 600-700MB

Storage space:
Without all dependencies, from pacman's "installed size".
Eclipse CDT: 320MB
Netbeans: 540MB
KDevelop + kdevplatform: 50MB
Of course, this will change if you don't have the dependencies; KDevelop depends on kdelibs (around 50MB, but depends on some more things itself) and friends, and Eclipse and Netbeans depend on the java stuff, so subjectively on an empty system (just plain X11 installed) I'd say it doesn't make much of a difference. Real numbers on what those IDEs plus all dependencies need storage-space-wise would be welcome of course. I would be very much surprised though if KDevelop (with all dependencies) would end up using significantly more storage space than Eclipse CDT (with all dependencies).
That being said, it's a stupid point anyways, because who cares about whether it needs 100 MB or 500 MB on your hard disk nowadays (I don't). If it required several gigabytes (like mathematica or so), I might complain, but in the few-hundred-megabyte-range, everything is all right for an application I use every day.

Startup time:
(until main window + all widgets shows up; "warm" start!)
KDevelop: around 3 seconds
Eclipse CDT: around 11 seconds
Netbeans: around 18 seconds (plus an extra at least 5 until a file shows up in the editor)

I'm perfectly aware that this is not a benchmark of any kind, or even a serious comparision. But maybe I just need to post some numbers in order to make people try for themselves if stuff is slow or not instead of just making random uninformed claims.

"$language is not supported"

Supported languages are: C++, CMake, PHP, Python, Ruby (not yet released but good), JavaScript/QML (not yet released and quite basic).
Everything else is indeed not supported, and if you need an IDE which supports that language, you'll have to implement it yourself in KDevelop, or use a different IDE.
But, be aware that "not supported" only means "no extra-fancy features". We do have syntax highlighting and such basic stuff for everything, from Action Script to Yacc, so you can edit files from other languages just fine.

"there is no GUI designer"

No, there is not. You can just use QtDesigner alongside KDevelop. How do you want QtDesigner integrated in KDevelop, do you want the designer window inside KDevelop? Or a "new UI file" button? What's the point?
I claim that if you understand how KDevelop is meant to be used, you will have to agree that there is little point in QtDesigner integration beyond having a template for "UI file with C++ class" (which we have), because all you could do is pinning the designer window into a KDevelop tab, which I don't see a point in.

"it's KDE so it's slow / bloaty / cannot be used under FOOBARDE /..."

"it's KDE" just means that it uses the KDE libraries which means it'll depend on some packages. Other IDEs have dependencies as well, they use a different set of libraries (when I installed eclipse for the test above, I didn't have java installed for example). I don't see a qualitative difference between depending on Java and depending on kdelibs.
It also doesn't mean you can't use it in other environments than KDE's plasma, that's a myth which just keeps popping up for whatever reason. It's about as pointless as claiming that you can't run vim on X11 because X11 is GUI and vim is terminal. Or so.
It also doesn't mean it'll be any slower in non-KDE environments. Of course, if you use a lot of KDE applications, they will, combined, use less memory and start up faster because of shared libraries, but that's an extra benefit you don't get for other applications anyways.

"the syntax coloring makes my eyes bleed"

First, you can turn it off if you don't like it. Second, try using it for a week -- I have yet to meet someone who turned it off after having used it for a while.
Here's an extensive explanation about how syntax coloring works.

"it's unstable and crashy"

It's not. There was problems with stability in the 4.1 era (wich was years ago), and there's a bug in some Qt versions before 4.8.3 which made it crash too, but the current version is perfectly stable.

That's about all. I hope that with this post I have covered most things that usually come up, so I can just link to this page when it happens again ;)