It's so much easier on Windows...
And I have a Linux at home, and I code at home, so I had a lot of time to experiment with alternatives.
I'm writing this now because at least one commenter did not bother to read the whole answer before commenting and potentially downvoting it. For example:
Hey paercebal, I would read your answer in full, if it would have more substance than rant. [...] for me. But, if you answer somebody's text, you definitely should read the whole thing. [extract from ypnos' comment]
I guess it means that ypnos did not bother to read my post, but (wrongly) accuses me of the same crime about a comment.
Anyway, for the downvoters out there, please:
- Don't comment if you did not read the whole post. Thank you. Yes ypnos, this is for you.
- Don't comment if you didn't read the original question. The author asked if it was harder to develop on Linux than on Windows. Sorry if I committed the crime of answering yes.
- Don't comment about how there is choice on Linux. Everyone knows that. I know that. I even tried that. Read again the question. Write your own answer.
- Don't comment about great tools if I already wrote I tried them and wasn't impressed in my post You're just showing you did ignore my post.
- Don't comment if a full answer would be better. The question needs viewpoints from multiple sources, so please write down your own experience instead of doubting mine.
Back to the subject: The IDEs
On Linux, I tried the following:
- etc. (miscellaneous generic editors)
Nothing compares to Visual Studio:
- Projects are eons easier to create and maintain
- The compiler is very very good (Visual C++ 6 is a long time ago).
- The text editor is very cool, including Intellisense
- Debugging is so much easier I don't even consider debugging a feature on Linux.
People will laugh at the fact Visual Studio is the "on tree that does almost anything", but then, it means that it works now for almost anything you want to do (and for most people, this means more than everything).
And I know you care about productivity and results.
In my personal case, I've had only ONE rare case where something worked on Linux, and not with Visual Studio, and as far as I see it, I just don't care about it. I'll use Visual Studio anyway even if I have 10 more of that cases.
At home, I have a Linux system, and have struggled to find a decent IDE (sorry, but using console tools is just a pain in the @ss). I tried Anjuta, as well as KDevelop and Eclipse, but finally settled on Code::Blocks, which I consider the best tool.
And Code::Blocks is nowhere near Visual Studio.
(Still, Kudos for the Code::Blocks developers...)
MonoDevelop could be cool, but I am mainly a C++ developer, and MonoDevelop is about C# (which is a worthy language, but then, I'm so much in love with RAII...)
Muaaah ah ah ah!
Sorry for the outburst, but I'm not an admin: I'm a coder.
I don't care about the full divine power of console tools that will do everything and more for me, if only I knew what existed and what it did.
The last thing I want in my life is opening a Vi console, EMACS, or using the autoconf framework.
Sorry, I can't bear the complexity, and don't want my "hello world" projects polluted by hundred of useless files I don't care about: The question is about "easiness of developing on Windows vs. Linux", not about "Hey, your Linux box can do me coffee, too, with the right bash script!".
The documentation could be cool, but then, nothing is centralized, and when it is, it's a console documentation (MAN is a pain to use, sorry). Just reading the automake/autoconf doc made turn away in disgust, and search for an IDE. JAM, BJAM CMAKE or whatever would be cool, but then, I don't care about the new Nth process of compilation some people reinvented because the existing (N-1)th did not work like they liked.
I have the strong impression that instead of updating MAKE to read decent makefiles (and not the disgusting mess it is now), people keep on producing console tools that produces files that are used by console tools that will produce scripts that will call g++ to compile your files.
Layers upon layers. Pleeeeaaaaaase...
The major reason, I guess, is that Visual Studio produces projects that works right out-of-the-box.
You can then rely on the GUI to learn about features, and make project changes, and if you need to automate project changes (as I did recently on 200 projects that needed some project cleaning), you can still examine project files (XML files!) to determine all viable options, and modify them.
On Linux, this is the contrary, you must know everything out-of-the-box before even starting a project, and while autoconf/automake seemed a good idea, the pollution of your "Hello World" project with unnumerable files is such you can't believe someone had the guts to produce such tools.
So, people could say perhaps that I'm spoiled by having developed on Windows.
Ok, I'll accept that. In fact, I assume that. Again, I'm a coder, not an admin.
And then, everyone I know is either "you should learn VI because it's the one editor that works everywhere" or "I develop and test on Windows and produce the final binaries on Linux". And I'm talking about professional development, where only our Linux/Solaris binaries are used by our clients. So, are we all wrong?
Someone mentionned the API, and the fact WinAPI is complicated, so I guess I'll speak about my experience about it.
WinAPI is not complicated.
The only problem I have with WinAPI is that it is C (I'm a C++ coder), and that its GUI framework is disgustingly hard to use compared with other recent GUI frameworks like GTKmm, QT, or even Swing on Java, or the equivalent on .NET.
But for other tasks, it is as easy as any other frameworks to use (because it's C, mainly).
- Wanna create files? Look at CreateFile (I'm not kidding).
- Wanna create a thread? Look at CreateThread (again, no kidding).
MSDN is a very good reference, but that will not be enough, as you must at least spend some time reading the major API functions for A to Z because starting.
WinAPI is an old framework (30 years?), but then, it works.
Just as everything else, avoid it if you're doing cross plateform code. And as everything else, avoid using undocumented features. And even then, Microsoft apparently does an impressive job to maintain undocumented features (try Raymond Chen's blog for more info on Win API).