I tried Eclipse a few years ago, and yea, it's Java-focused (and laggily Java-built) nature made C++ work annoying. QtCreator is awesome on Windows though, as far as IDEs go.

Once my patience meter is back to 100% I'll give it a try.

I have been working on training material for C++ beginners. [ ... ] So I settled on Eclipse because it's available and for everyone. [ ... ] I didn't count on still needing different C/C++ compilers/linkers/tools. I had hoped they would just work. Not a big deal, but just frustrating.

Use QtCreator. It will just work on Windows and Macs, don't know about Linux but I bet it will just work there too.

I used Eclipse + CDT for C++ on Linux in about 2007 or 2008. I chose this setup because I am not a Linux person but had to write C++ on Linux for a job and felt I wasn't willing to climb Emacs' learning curve (Didn't like the job that much...) Anyway, it SUCKED.

Maybe it's gotten better but I kind of doubt it.

Maybe it's gotten better but I kind of doubt it.

It's pretty seamless to install these days (on Linux and Mac - the Windows install experience still sucks).

Actually developing software with it, however, is another matter. It's our default development environment at work, and I'd give my eye teeth to be able to perform C++ development in Visual Studio instead.

I have been working on training material for C++ beginners. [ ... ] So I settled on Eclipse because it's available and for everyone. [ ... ] I didn't count on still needing different C/C++ compilers/linkers/tools. I had hoped they would just work. Not a big deal, but just frustrating.

Use QtCreator. It will just work on Windows and Macs, don't know about Linux but I bet it will just work there too.

I used Eclipse + CDT for C++ on Linux in about 2007 or 2008. I chose this setup because I am not a Linux person but had to write C++ on Linux for a job and felt I wasn't willing to climb Emacs' learning curve (Didn't like the job that much...) Anyway, it SUCKED.

Maybe it's gotten better but I kind of doubt it.

Using Linux-focused tools on Windows make you a second-class citizen of both the Linux world and the Windows world. It puts us in a grey immigration zone where nobody acknowledges our existence.

Hopefully Clang will change the 'intentional difficulty' issue, but so far Clang hasn't exactly been too interested in Windows all that much either.

Eclipse isn't a Linux-focused tool... it's a Java-focused tool

I was referencing MinGW's buggy debugger and the lack of a free Windows-equivalent of Valgrind.

I tried Eclipse a few years ago, and yea, it's Java-focused (and laggily Java-built) nature made C++ work annoying. QtCreator is awesome on Windows though, as far as IDEs go.

Ah. As a Java tool, Eclipse is pretty good on Windows, and does actually work smoothly between Windows and OSX (I haven't tried Linux). But it always struck me as a bit silly to use a tool designed around Java to do something other than Java. Even with plugins, doing web-dev stuff in Eclipse didn't seem that neat for example.

Last steady job had me doing a JPA web app with a JSF frontend and Android client. Code was stored on SVN, built by Maven, all from inside Netbeans/Eclipse.

Sometimes I think the universe is out to get me.

But it always struck me as a bit silly to use a tool designed around Java to do something other than Java. Even with plugins, doing web-dev stuff in Eclipse didn't seem that neat for example.

There are lots of projects like JDT for other languages that run on top of Eclipse runtime, adding support for C, C++, Javascript, Prolog, Python, Ruby, XML, etc.

What I meant is that because a "framework" is made in one language it doesn't makes it tailored to it. Think of Eclipse as it were Visual Studio, it has a base that provides the basic environment, then the specific language support is added on top, in the end you get different versions of the same tool set that work for different languages.

I certainly feel the pain of so many OSes, devices, languages, frameworks, tools, applications, and the impossible grind to stay current with enough of them (and deeply enough) to feel confident of an ongoing development future.

But my personal bugbear is with the everyday - in my case .NET web development. Don't get me wrong, Visual Studio is amazing and wonderful, .NET has some really nice features. But the current trend towards MVC, dependency injection, LINQ, etc means that you don't actually know how anything works. Everything is built on layers and layers of magic. It's like living in a flying castle. It's f###ing cool, but at any moment opening the wrong door may send it plummeting out of the sky for reasons that you will only understand in hindsight, or not at all. In the old days code was nice and linear. You step step step until you eventually get to the broken line. In these systems everything is connected by string and magic. You don't know which code is being run. MVC routing, some mystery algorithm chooses which controller method to call. You can be 110% sure you know which action will be called, but you may be wrong. When it does get to the right action, it calls a bunch of methods on unknown objects that implement some interface, and where do those objects get their values? I never set them. Are they instances of what I think they are? Who knows. Then your data layer stuff is done by LINQ, which sometimes allows the same syntax for the DB as for objects and sometimes doesn't. It converts it into the most g**damn ugly SQL you've ever seen in your life. Oh maybe we'll do it inside a lazy evaluated async Task! Oh that's cute, I thought that I had already retrieved the data from the DB, but it's now throwing DL errors in my business logic after I've exited my try/catch and it has no f###ing idea what to do with that exception. Get past that and then you get to the views which are often loaded by naming convention and sometimes lose intellisense for no good reason.

It is possible to figure out how it works, but it's like being told to RTFM (the whole manual) before debugging the simplest problem. Or searching for likely culprits and using shotgun breakpoints to brute force the problem. I've worked my way through so much of that stuff. Most of it is good and fine now, but there's always little traps. Not to mention the odd new issue where you just don't know what you don't know. Like when I deployed to a live server and all styling and images disappeared because IIS had a MIME mapping set up which dev and staging didn't, and web.config tried to set that mapping up. All MIME mappings corrupted, nothing beyond HTML content being served. Oh, how we laughed and laughed.

And then there's CSS, where 70% of stuff is easy and 30% requires some kind of mental jujitsu to achieve seemingly simple effects (e.g. layouts that one could achieve using HTML tables or Windows Forms while drunk and concussed on a rollercoaster). Add browser compatibility and responsive design, and it's a field of it's own almost as orthogonal to programming as print design is.

And then there's CSS, where 70% of stuff is easy and 30% requires some kind of mental jujitsu to achieve seemingly simple effects (e.g. layouts that one could achieve using HTML tables or Windows Forms while drunk and concussed on a rollercoaster). Add browser compatibility and responsive design, and it's a field of it's own almost as orthogonal to programming as print design is.

You know, I have very little to do with web programming anymore so I don't really care, but in my humble opinion CSS is the most broken little fucker of any technology in common use. I've read people's rants against PHP so that might be another one I don't know, but I do know about CSS.

CSS is just not the right thing. The cascade itself is not what you want. The cascade gets in your way more then anything else and whose idea was it to shoehorn layout into styling anyway? Why is that even a good idea? There needs to be a way to layout HTML that is external to HTML: fine, provide a sheet for layout with primitives for, oh I dont know, doing layout? It needs to degrade gracefully across heterogenous browsers/configurations ... okay, have it degrade gracefully across heterogenous browser/configurations and have some language constructs in which you can override how it degrades or whatever.

I don't see why any of this was rocket science.

Oh, CSS and the HTML 5 hype. Don't go there.

CSS: It should be so easy to make a slightly dynamic layout with a few fixed divisions. But actually, it's hell. Weird that the boo boo devil tables is a lot easier to use.

And then HTML 5, the never ending "standard".

It's the most concocted mess that people could come up with. While some of the basic ideas sound good on paper it's a clusterf*ck of epic proportions. "Living standard" my ass. Anything that's not nailed down is not usable as a standard.

Finally most systems will stay different for years to come. Thanks Steve as hailing this as new future and actually actively failing to deliver it while others are lightyears beyond.