0

There's a question that might be deemed a duplicate of this one (I use an IDE (Eclipse) to develop software. Why should I switch to vim or emacs?) but I don't think answers my question.

I usually program in C++ (not exactly to create GUIs so rather low-level) and I find myself comfortable with editing code into visual studio, compiling it and debugging it.

I know that all of this can be done in a linux/unix environment (even on Windows) as well, but I'm wondering how come that many low-level programmers are proficient with tools like emacs which I suppose hasn't any debugger integrated (no breakpoints setting, doing that with gdb seems pretty slow and really unhelpful).

How can they develop a complex software with a write-compile-debug cycle in such environments? Am I missing something? I doubt that they develop code in Eclipse, Qt Creator or Visual Studio and then get back to their textual tools.

Community
  • 1
user129506
  • 33
  • 1
  • 3
  • 2
    Actually emacs does have an integrated debugger: emacs gdb mode (http://www.emacswiki.org/emacs/GdbMode). It provides a GUI front end for gdb within emacs. Personally I find GUI debuggers overrated. They spare you the trouble of learning the debugger command structure, but that seems to provide folks with an excuse never to learn the extended capabilities of their debugger, like scripting and macros. – Charles E. Grant Jul 15 '14 at 23:14
  • I have seen one person doing development without IDE and debugger. How can they do it? They worked slower and perhaps do more planning (because they can't re-factor on large scale their code without the IDE, that I guarantee you. In fact I was even asked to help with refactoring something as simple as Eclipse's Alt + Shift + R) – InformedA Jul 16 '14 at 01:19
  • 1
    Wrong assumptions: Emacs is an IDE, and it has a comprehensive debugger integration. See `gud` with `gdb-many-windows` mode. – SK-logic Jul 16 '14 at 07:31
  • I did program in Visual Studio in Windows and fled back to ViM and used ViM to edit all sources even when I then compiled them with Visual Studio (from command-line or from ViM with a tiny bit of hacking to get quickfix to work) and only used the IDE for debugging. Because I am simply orders of magnitude more comfortable in ViM than the crappy editor in Visual Studio. And now we have _youcompleteme_ with clang completion ViM even has more reliable completion for C++ than Visual Studio. – Jan Hudec Jul 16 '14 at 09:12
  • @randomA: I have yet to see an IDE with working refactoring for C++ (as opposed to Java and C# where it usually works). Most of the time you are down to regular expressions and search and replace and Emacs and ViM are better with those than most IDEs (besides, Emacs and ViM _are_ IDEs anyway). – Jan Hudec Jul 16 '14 at 10:08
  • @Jan Hudec My mistake, I should have included Java in my comment. I have no experience in development of large C or C++ software. – InformedA Jul 16 '14 at 10:14
  • @randomA: The question explicitly mentions C++. And the situation is really different between C++ and Java, because Java always had programmatically usable parser and it is easier to parse. But C++ only got reasonable parser with API recently with Clang. And even then C++ is often compiled with many different options that a refactoring tool can't easily cover. – Jan Hudec Jul 16 '14 at 11:41
  • @Jan Hudec Ok, I didn't take what the askers said as to C++ exclusively, but anyway, good point. Cheer. – InformedA Jul 16 '14 at 12:02

3 Answers3

3

Emacs does some things much better than other editors:

  1. Startup time. One of the most important features for an editor is startup time. With IDE you need to wait 30 seconds to get your project to open, and another 30 seconds every time you switch to another project. Emacs just starts up so fast that editing software is easy.

  2. Multiple instances. There will be multiple copies of emacs running. Not just single ide, but multiple copies of the text editor.

  3. Large files. You'll end up having large amounts of code in single file. If your editor breaks when it loads 20kloc file, it's useless.

  4. Searching. Finding correct place inside your code needs to be easy. Right way to do this is proper searching from within current file.
  5. Navigation. Beginning-of-file is one of the most important features.
  6. Goto-line. When compiler gives you error, it has line number included. goto-line will allow you to type the line number and instantly find the correct place in the code.
  7. Buffers.. Both header file and .cpp file needs to be visible at the same time. Multiple editor buffers with split-screen are essential for seeing the source code.
  8. Loading new files. Switching between files is rare, but necessary feature.
  9. Saving. If your editor loses the code if you simultaniously edit the file from two copies of the editor, its no good. Emacs saves the code correctly every time.

Text editors are not suitable for compiling, debugging your code. Instead, the following tools will do the trick:

  1. Compiling will work with makefiles from the command prompt. Typing "make" in command prompt will do the trick.
  2. Debugging will use gdb and valgrind. Both of them are useful for getting call stacks. Trying to do single-stepping through the code is just waste of time.
  3. Version control with git.

Note that these are outside of integrated development environment.

tp1
  • 1,902
  • 11
  • 10
  • Emacs can run `make` or other suitable build command for you and it can also embed a gdb session. So it actually can do everything IDE can. ViM can also do all those things except embedding gdb session (even that might be possible, but vim less suited for it). – Jan Hudec Jul 16 '14 at 09:08
2

Basically, sometimes you prefer things more tightly integrated and streamlined, sometimes you want looser integration with hopefully wider choice of parts.

Hint: source-level debugging is also available via gdb.

There are also various build systems, some possibly superior to, or more flexible / extensible than what is built into VS.

No doubt, having everything integrated is often convenient.

In different circumstances, you could benefit from an ability to run a debugger on a remote machine two firewalls away (via ssh), or on a tiny embedded system.

It is not impossible, of course, to integrate various tools into a scriptable editor; both Vim and Emacs have modes for interaction with various debuggers, build systems, version control systems, etc. Some prefer these other tools.

It is also possible, of course, to create some kind of remote debugging probe or an exotic VCS interface for an IDE (like VS). But this begins to become suspiciously similar to the approach above :)

The strong point of IDEs, to my mind, is superior source code handling: navigation, refactoring, validation, frameworks support, everything that having a properly indexed, AST-represented code base gives you.

9000
  • 24,162
  • 4
  • 51
  • 79
  • Good answer overall. I would want to add a few things. I doubt that people use bare editors because they want wider choice of parts. Editor users back in my undergrad used them because they couldn't grasp the complexity of IDE. Some of them are good enough to get to the workplace still don't use debugger. Even they are not even aware of the O(logn) benefit in using debugger to fix bugs. As for remote debugging, it's far better to create a mock-up environment unless the environment is a large server cluster. In case of micro environment, mock-up and local debugging is a much better option. – InformedA Jul 16 '14 at 03:09
  • As a long-time user of both Emacs and Vim and a former developer of [an IDE](http://www.jetbrains.com/pycharm/) I'd like to notice that while things like notepad.exe or nano may be "bare", serious editors (Emacs, Vim, TextMate, UltraEdit, Notepad++, you name it) are quite "furnished" and, what's important, _extensible_. They are quite sophisticated at one task: editing text. – 9000 Jul 16 '14 at 04:33
  • I want to add that, among those using bare editors, a minority those that made it through schools are actually very good in general sense, and in many things. In fact, the majority of professors just use bare editors. – InformedA Jul 16 '14 at 05:24
  • btw, by bare editors, I meant a standalone editors without integrated functionalities. The 'bare' was supposed to be for 'only used for editing'. Not in it is simple and unfurnished. – InformedA Jul 16 '14 at 06:09
1

I'm presently developing software for embedded systems and an occasional PC application.

I have the following applications open during coding and debugging:

  • XEmacs -- Has nice features that Eclipse doesn't. Also doesn't force a file tree on you.
  • Visual Studio -- Nice debugger. Can write console programs to test embedded functions.
  • Parasoft C/C++ Test -- A Static Analyzer built on the Eclipse frame work. Can edit can compile using the target compiler; but can't access the JTAG debugger to the target device.
  • IAR EWARM -- IDE with capability to talk to a JTAGJet debugger to our target platform. Decent debugger, builds in the target processor's tongue, but lacks the analysis of the static platform.
  • Command Window -- For running Coverity Static Analysis scripts.
  • Cygwin Terminal -- Unix has nice features like find and grep.
  • UltraEdit -- used to edit batch files; can print syntax highlighted source code with line numbers to color printers!
  • PTC -- Code Management System for checking files in and out.

I can't find the "one true GUI", so I have multiple applications open. I find Eclipse very nice for Java and a pain for C or C++.

I also grew up programming before the IDEs were invented. So, one would edit the file, close the editor, then build using a command line system (like make).

A lot of GUIs I have looked at are trying to sell a company's tool chain set. You either by all of the tools to get their good GUI or nothing.

In summary, I develop code by bouncing around in applications. There is no complete IDE that contains all the functionality for programming an embedded system and has features that I like and few of the ones I dislike.

Thomas Matthews
  • 387
  • 1
  • 8