JetBrains is working on a cross-platform C++ IDE
jetbrains.com
jetbrains.com
Do you also tell people that they shouldn't use flex/lex/bison/yacc/antlr/etc.? Why are those code generators/DSLs acceptable but the moc is not? It's not as if the Qt authors added it because they don't understand C++, they added it because it solves a vexing problem in C++ GUI design.
Every Qt "keyword" you talk about can be disabled with a fallback to namespaced macros.
foreach -> Q_FOREACH slots: -> Q_SLOTS
etc.
I currently use eclipse for my embedded C++ project, and QT creator for QT apps (QT is wonderful!), but intellij for pretty much everything else. Looking forward to this.
It works pretty well for me. Even sublime text would do the job since it has all of those features too.
What do IDEs have over Vim in terms of features that I may be missing out on? For java, I would definitely use IntelliJ because of the debugging features alone but I think it's overkill for something like C/C++/Python
For Java, you really can't get decent code checking with vim unless you use a the eclim plugin and that just feels like a hack.
I personally use RubyMine, and while I don't use the debugging a whole lot, it comes in handy with some really confusing issues. Other than that, it is just a fancy text editor that I have become used to for Ruby work.
Even the build system is quite simple...
What about instantly knowing who calls that method or uses that class or that variable, with much more flexibility than just grepping through the code?
Those are the features I use the most in any IDE.
I think IDEs hurt innovation in development tools more than almost anything else. They are like crack for your workflow - easy to get started with, but once you're on them you're stuck. Plugging in better tools into existing IDE is a big PIA if possible at all, and rewriting the whole IDE is a huge undertaking for any company who wants to make your life better.
Standalone utilities generally have poorer UI and require more effort to find and run.
Using vim, emacs and similar always leaves a taste of doing a time travel to the early days of UNIX using text terminals.
Yes. And it has been done. Over and over, each approach crappier than the next.
I'm using Eclipse/CDT; it's really shitty, but sadly still more usable than Vim for large (-ish) projects.
It also has ctags support so you can navigate your code, go to a method/variable/class name and instantly find out where it was defined and such.
It seems to me that IDEs such as Eclipse, VS etc. are much better suited to large scale development than vim.
For example, recently I worked on the HotSpot JVM, beginning by analysing the codebase. I started with vim and got cscope and related tools working, but they didn't seem to always work, and were much less useful than those I'd used in IDEs. In the end I switched to Eclipse, and was able to carry out the analysis very easily.
One of the Oracle JVM engineers told a friend - they generally use emacs for development, but when someone is trying to get their head around the code, they use an IDE.
So it seems to me that this guy and others "internalize" the way they codebase works, and then subsequently switch back to editors.
Thing is, this all seems rather baffling to me. Surely IDEs are designed to remove a lot of the burden of memorizing syntax, APIs, and the way the codebase works. Intuitively, this sounds like a step forward.
But - lots of experienced and smart programmers still use vim and emacs rather than VS, Eclipse, Qt creator, IntelliJ. Those people know a lot more than me about coding. So there must be a rationale for sticking to text editors.
Can anyone enlighten me please? Should I invest more time in emacs/vim? If yes, why?
Why bother thinking about a clean separation of concerns, isolated modules and good interfaces? The IDE will let me change any method or class name at any time, so I can just use everything everywhere as much as I please. Why bother making minimal well documented interfaces that make sense? I can just make sloppy, huge interfaces with 100s of little functions and use my refactoring and completion tools to find out which ones to call.
I call systems built this way "boogeymen". They are really scary to work on. You're changing some method in some class and you have no idea what will be affected by that method (until you run the system or the tests). You have no idea if that public method is part of an interface to the larger module, or its just public because another class from the same module is using it. Come to think of it, there is no "real" modularity and isolation.
I strongly believe that "necessarily complex system" meme is a myth and complex systems are the result of sloppy work on architecture, modularization and tiny interfaces that make sense. IDEs help perpetuate this sloppiness by helping mitigate the consequences, not by solving the underlying problem
As for finding what calling methods there are, as other have stated, you can use ctags, or go full throttle with Cscope - http://cscope.sourceforge.net/ it will do textual searches along with displaying all callers for a method across all the files you tell it to search (in setup).
With the vim gui and a cscope backend, I'm pretty sure vim is just as much an IDE as any of the other editors. It just happens to work fine in a terminal, too.
<guy never having run more than a mile> 'Yeah I'm pretty sure that these 7.95$ Walmart sneakers are just fine for running the NY marathon, why would I need those Nike's or Asics?'
Neither is better for me than vim and unix tools, even if I have to run under cygwin. It's cool that jetbrains is making something new, I just wanted to point out there are few (if any)features vim and/or emacs do not have.
Not sure if you're trolling, but how much C++ do you write? If you have to ask what the difference is between VS and Vim, and are suggesting that writing C++ is more like Python than Java, you haven't used C++ and/or VS much.
(context: I have 10+ years of experience with VS and 15+ with Vim, which is my everyday editor for everything except non-trivial C++ code)
Further more the skills feel more real, I can apply my usage of vim and how the tool chain works to other languages.
Not having used AppCode I don't know how good the support is for C++ already. I wonder if they will be using clang/llvm for static analysis? Though I don't know much about that area, I've noticed that all C++ IDEs that I've tried (including MSVC++) are much poorer than Java IDEs in that aspect.
From the page:
"The IDE will be integrated with Clang Analyzer, so that more than 2000 code inspections and error diagnostics results from Clang compiler would be shown right in the editor. Of course, you also would be able to review them in a bulk mode"
Just a thought.
It's not too hard. I currently use Swing in Java, all written from scratch - no IDEs to be found. I've also dabbled around with simple GTK+ apps. They aren't as easy, nor as efficient, to work with as the standard Java toolkit, but you get used to it.
I switched back to Swing because I wanted as few dependencies as possible.
> I'm using IntelliJ IDEA on Linux since version 4 or so (we're now at version 12).
> And I agree with you but...
> The trick is to use a pixel perfect font with no anti-aliasing at all and to set the correct vertical spacing between lines and then IntelliJ is just going to look fine (for a Java app).*
> So first you go download a real font (a font made especially for programming, like the Proggy fonts which you can get at proggyfonts) (I take the .ttf version)
> You relaunch IntelliJ and then go to:
> Settings / IDE Settings / Appearance / Editor / Colors & Fonts / Font and then you set your pixel perfect font, say :
> ProggySquareTT (Size: 16, Line spacing: 1.3)*
> (oh and btw IntelliJ is so stupid that if you have "Show only monospaced fonts" checked it won't understand that Proggy is monospaced and hence not show it into your fonts choice list)
> I'm 40 years old and still have 10/10 eye vision, which I attribute to two things: avoid dark characters on light background scheme anytime it's possible and never ever using anti-aliased fonts (which are blurry)
> "Pixel perfect" is the way to go here. And anyway anti-aliased fonts under Linux are so fugly compared to OS X / Windows that you're really not missing much by going pixel perfect.
> Regarding the other IntelliJ IDEA fonts (the ones which are not the editor / console), I'm stealing a Tahoma.ttf from Windows and settings everything to be Tahoma.
> Same for my Emacs but for whatever reason under Emacs I'm using Terminus and not Proggy at the moment ; )
> Now of course it's really sad that the only "ok" desktop UI ever made with Swing is the one made by JetBrains: it took people who wrote the fscking most advanced Java IDE to come up with a reasonably looking Java Swing app : (
> The Eclipse guys didn't even bother and created their own UI (SWT) which kinda speaks volume about the nameless mediocrity that Swing is : (
http://www.sublimetext.com/blog/articles/sublime-text-2-0-re...
In short, they used the native libraries on Mac OS X.
Keyboard shortcuts, drawers, and focus passing would randomly fail to work, since Qt was welded into the Cocoa event system and sometimes missed rather important edge cases. For instance, pressing the Esc key was programatically indistinguishable from clicking the 'Ok' button in custom drawers. More often, power-user shortcuts were overridden, didn't respect configuration changes, or entirely absent. Some views (table view IIRC) didn't even try to exactly mimic the native look and feel. Menus worked in fundamentally different ways on different platforms: if somebody designed an app to work on Windows, which does menus on a per-window basis rather than globally, menus would randomly appear/disappear on OSX. Oviously this wouldn't be a problem if all your users knew about it, but they won't. Integration with launch services was absent or crippled. Docking windows required tons of theming if you didn't want them to look like crap. Sometimes constraints or conventions imposed by cocoa were overridden, leading to subtle differences in the positioning of button text and so on. I spent 2 person-days hunting down the cause of a 2-pixel border between the edge of one view and the window backing; the hunt ended in failure when I realized that I would have to monkeypatch or completely replace Qt's layout system in order to get the view snug against the edge. Sometimes Qt's abstraction layer led to unacceptable performance tradeoffs that would be easy to solve on any given platform but were simply not addressed in the Qt API. In general, the UI design tools didn't enforce platform-specific conventions and were miles behind XCode in terms of ease-of-use.
I had a few problems that weren't specific to integration, but they were just as frustrating. The documentation, while great for an open source project, was still far behind the status quo for native libraries. I found their documentation on coordinate systems very difficult to understand (in comparison with the Cocoa documentation) and sometimes it was just plain wrong, e.g. about mouse event propagation within graphics views (and you would think that would be a fairly heavily trafficked page, no?).
If you want your Qt app to seem native, you had better be prepared to dig through Qt itself and patch its deficiencies. This often means being intimately familiar with the native libraries, since the bugs reside at edge-cases the Qt devs weren't thinking about when they wrote the code.
Honestly, if I had to do it all over again, I think I would have just insisted coding the front end twice using native libraries and development libraries each time.
However, it is not inconceivable that one could maintain a unified codebase and use a few platform-specific hacks to ensure that your app "philosophically matched" each OS. Quite possibly, one could still save net effort by implementing these patches vs maintaining a split codebase. If this were the case, I would be happy with Qt and I would sing its praise.
My difficulty with Qt stemmed mostly from the bugs. It simply lacked the polish of Cocoa and .NET in a way which noticeably and negatively impacted productivity. "Platforms are different" is no excuse for incorrect documentation, layout engines that are 1-2 pixels off at the edges, broken/incomplete keybindings, missing integration with launch services, and so on. I have the utmost respect for the Qt team -- I wouldn't have guessed that anyone could come so close to unifying the major UI kits -- but Qt still fell short of where it needed to be if it wanted to compete with the native toolkits.
Qt applications have at least made it to the point where the scroll bars are correct and the menus usually include the standard structure and emacs keybindings work in text boxes, but I've yet to find a Qt application that has a properly integrated help system, and almost every one quits the application when the last window is closed, native toolbars are rare, combo boxes seem to be used frequently where pop-up buttons would be more appropriate, and nobody seems to add any options to the dock icon's context menu. I've seen enough to know that Qt can be a very close approximation if the effort is put forth to make the app act native (probably better than any other cross-platform toolkit), but it's far from free, requires a ton of platform-specific code, and apps that try hard are few and far between.
The non-GUI part of the framework is a quite decent as well.
IntelliJ was almost perfect for Java (last used it 3 years ago), other than the ridiculous memory usage and the constant freezing which I'm pretty sure the JVM's GC was responsible for.
I've been using Qt Creator for C++ code for the past 3 years, and it's so much faster and non-laggy it's lovely - even when having some serious things missing (multiple monitor support).
BTW: Comparing it to Qt creator is very unfair, because Qt creator does not have half of the features included in IntelliJ. E.g. refactoring / inspections / full type-aware error highlighting (not just syntax checking).
There used to be a blog series explaining developers how to take advantage of Swing to make nice UIs. The problem is that most don't care and use whatever is the default.
Love jetbrains products. Best $200 i ever spent on Ultimate
I can't follow the deletionists' logic. I hope nothing else is going on -- like a competitor trying to remove information about them.
Kotlin's removal in particular is strange, since several other JVM languages persists at Wikipedia, some of them much less well known than Kotlin. Still there are: Gosu, Ceylon, Fantom, Ioke, Seph, Groovy, Boo, Nashorn, Frink, Pizza, Pnuts, X10, Xtend, etc.
Very strange.
It's certainly better known than any of those other languages you mentioned. In fact, the two greatest innovators on the Groovy language, James Strachan (original creator of Groovy), and Alex Tkachman (original creator of Groovy's static mode), were "encouraged" to move on from Groovy by its present leadership, and are both now contributors to Kotlin.
Visual Studio works great on cross platform code bases. It is so much better than Eclipse, but I'll stick with vim :)
Plus, if you're looking to build a cross platform GUI app, Qt is a great toolkit, and Qt Creator (as the name suggests) supports drag&drop UI building, QML etc.
I find that compilation in Qt Creator is possibly slower if you are on windows (using mingw) but on Linux its around 10 times faster (through the use of ccache and make -g4).
And the documentation is awful. I still haven't figured out how to make precompiled headers work with clang (but that may be my fault).
There is a relatively new clang based vim plugin that I haven't tried yet. Using clang to parse C++ into an AST is the right approach, so it sounds promising.
When people rave about Visual Studio, they are mostly talking about C# development. And even there, they often talk about Resharper.
That said, install Visual Assist X and Visual Studio becomes quite a decent C++ IDE. That does not fix debugging or the compiler of course, but refactoring, highlighting, code navigation, contextual cues and auto completion are mightily improved.
Contrary to many in FOSS think, all C and C++ compiler vendors have language extensions and gcc is not immune to this.
You're right. We don't need more. Let's just stop trying to make things better.
Wakey, wakey. JetBrains is investing time and money (or is that the same thing, anyway?) to develop a new C++ IDE, a market (though I don't like that word) where nothing new has sprung up in a while. That's __good__ news, what's the matter with you? Can it harm you?
IntelliJ incorporates everything found in all the other IDEs like RubyMine and PyCharm but doesn't include the additional stuff found in AppCode.
Hi from JetBrains,
This is a short but important note about the C++ IDE we revealed yesterday: Yes, it was an April Fools' joke, but the IDE is actually real.
Thanks for believing and subscribing to the list. As soon as we have something ready, you'll be the first to know and try it out. Stay tuned!
Oh, and if you use a Mac, you are welcome to try C/C++ in AppCode and let us know what you think.
Develop with pleasure! The JetBrains Team www.jetbrains.com
When dealing with C/C++ or ObjectiveC I expect something that's very light and quick to load - not something that feels this bloated!
BTW: measuring memory usage on a Hello world project is pointless. You can't extrapolate this value to memory usage on large projects. Most of this memory is just code of the IDE and plugins, which does not depend on the project size. I work on some really huge projects in IntelliJ Idea, sometimes 3 or more at the same time and it never needed more than 512 MB of heap, which is pretty impressive result, considering how much it actually does (all the inspections / type checking / background compilation / autocomplete come at some price in memory usage; most of the C++ editors you mentioned don't support them to such extent, or sometimes at all).
I take it that you haven't tried coding on Visual Studio? Just because you have the memory, it doesn't mean that you should be using as much memory as you can.
> I work on some really huge projects in IntelliJ Idea, sometimes 3 or more at the same time and it never needed more than 512 MB of heap
That's because that amount is set as the maximum heap size. If any more memory is required, the disk swapping becomes heavier and heavier. Have a look at your idea.vmoptions file to see what the maximum allowable usage is set for your install.
> most of the C++ editors you mentioned don't support them to such extent, or sometimes at all
They don't support it for C or C++ due to inherent limitations in the compilation of the language - not because they are unable to do so! Visual Studio does all of what you've mentioned for languages which compile to an IL code (i.e those that rely on the .NET framework) with great ease.
> If any more memory is required, the disk swapping becomes heavier and heavier.
If any more memory would be required it would not swap, but OOM. Again - if you ever need to swap, then you must be coding on a netbook...
> Visual Studio does all of what you've mentioned for languages
Nope. Not to such extent as IntelliJ is doing it. You need Resharper for all of that. From JetBrains. And VS can easily grab 500 MB of RAM too, especially after a week of work without restarting it (memory fragmentation, maybe some leaks).
Please read up on virtual memory.
> You need Resharper for all of that. And VS can easily grab 500 MB of RAM too, especially after a week of work without restarting it (memory fragmentation, maybe some leaks).
VS2012 includes many of the features provided by ReSharper. What does restarting an IDE have to do with this? My point still stands: an IDE should be light-weight and responsive. A heavy memory footprint (which is a hall-mark of Java-based IDEs) is not helpful in achieving this regardless of what kind of machine you're running it on!
Great feature, but it's Doxygen with a 'y'.
That was a bit harsh. It definitely isn't VS, but there is code navigation, auto completion, debugging etc.
intellij idea used to have a third-party c/c++ plugin, which was ok, but it stopped being maintained a while back. this was frustrating because otherwise you can develop in intellij in most popular languages. so c/c++ support had been a strange omission for some time - see this support issue, for example - http://youtrack.jetbrains.com/issue/IDEA-86304
(i haven't seen anything saying that this will be an intellij idea plugin - but afaik that's how all their other products work).
What I miss in Netbeans is an integrated static analyzer like Eclipse's CDT (Codan).