Emacs and LLDB

Posted Feb 13, 2015 16:48 UTC (Fri) by rriggs (guest, #11598)
Parent article: Emacs and LLDB

Reading this article is akin to watching an argument among cavemen about which rock to use. FSF has lost the battle long ago by not competing with Visual Studio, Eclipse, IntelliJ and NetBeans. This is where the battlefront has moved to. The FSF never showed up. As these tools switch to LLVM for C/C++ parsing, GCC will quickly fade from use.

Emacs and LLDB

Posted Feb 13, 2015 17:48 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (2 responses)

I know I'm a tiny minority, but none of those tools are really useful for me for actually editing code (other tasks, maybe) because I like Vim bindings and every Vim emulation support in any of those is an abhorrent half-breed where half of my muscle memory is broken (typically with <C-w> not being "delete word").

Emacs and LLDB

Posted Feb 17, 2015 15:41 UTC (Tue) by rriggs (guest, #11598) [Link] (1 responses)

"Editing code" is a quaint notion of what a software engineer does these days. Having refactoring tools readily available, code completion, tooltips with API help, among many other features basically provides an expert system to help one write complex code quickly.

Whether designing GUIs for Android apps or managing complex pin assignments for an ARM microcontroller, one needs a tool like Eclipse to help get the job done quickly and efficiently.

Muscle memory can be retrained very quickly. Pro baseball players can still learn how to swing a golf club. Switching between Eclipse and Vi is no different. I use both every day. But I can rarely work effectively all day in only one tool.

Emacs and LLDB

Posted Feb 18, 2015 20:54 UTC (Wed) by k8to (guest, #15413) [Link]

You're presuming every project is similar to yours. Some benefit greatly from this tooling, some don't.

Emacs and LLDB

Posted Feb 17, 2015 21:10 UTC (Tue) by mister_m (guest, #72633) [Link] (1 responses)

The assertion that the FSF has failed its mission because they have not produced an IDE is frankly ridiculous.

Emacs and LLDB

Posted Feb 18, 2015 21:00 UTC (Wed) by k8to (guest, #15413) [Link]

Well, it is true that they went from providing what was viewed as a relatively full service development to something that is viewed as limited is certainly true. Some of this is perceptio. Some of it is low-quality overly verbose languages. But a lot of it is working with extensive classes and frameworks that the user can't possibly be expected to know, and advances in refactoring workflows that are well-supported at least with a subset of languages.

The short version is: codebases got bigger, and more powerful tooling to interact with them became more important.

You can get decent support for this kind of work in vim and emacs, but you have to be quite savvy to set it up, and it's a rare developer who does.

I certainly have never really looked to the FSF as a complete development tools provider though. Even in the heyday of gdb and gcc, I still relied on things like cscope and proprietary instrumentation tools.

Emacs and LLDB

Posted Feb 19, 2015 4:36 UTC (Thu) by linuxrocks123 (subscriber, #34648) [Link]

This argument again?

There are certain codebases where IDEs work well, and certain codebases where they don't. In either case it is certainly possible to code using a text editor and not lose much productivity; you just need (for example) DOxygen in a web browser so you can quickly look up API calls. Is it exactly equally as good, no, sometimes it's better and sometimes it's worse. I used an IDE in a project where I added stuff to the Java compiler and it was a boon to be able to use IntelliSense to find the right API call. I didn't even consider it with my current Python project because Python doesn't provide the static typing needed for anything like IntelliSense to even work.

This is just a dumb argument, partially because you can shift goalposts by calling Emacs an IDE or SlickEdit a text editor. I personally don't like setting up projects with classical IDEs and find they can be very brittle sometimes, but I'll use them when they're the right tool. But even if I didn't, I could get by fine without them, and I expect most good developers could, too. Browser-with-autogened-docs can replace most of the advantages, especially if you have two monitors. So, it really comes down to personal preference, so let's not argue Vi versus Emacs in its modern incarnation.