Design News is part of the Informa Markets Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Terminal Versus IDE Development, FIGHT!

Image courtesy of Pakpoom Phummee / Alamy Stock Photo IDE GE2RDE.jpg
Close up of an IDE Hard disk.
Terminals and integrated development environments (IDEs) each offer benefits. How do you choose?

You may or may not have noticed that a silent war is being fought between developers using terminals and those using integrated development environments (IDE). When I started developing embedded software, the process was utterly terminal-based and a bit of a nightmare. When IDEs became mainstream, they simplified and abstracted the development process, making it easier and faster to develop embedded software. Recently, I’ve noticed scoffing at using an IDE despite its many advantages. This blog will explore the benefits of using terminals and IDEs and try to set the record straight.

Why Should Developers Use the Terminal?

If you want to get into the bits and bytes and understand what is going on under the hood, the terminal is the place to do that. To use a terminal, you need to know the commands for your tools and how to get them to do what you need. For example, if you are debugging an embedded application using GDB, you need to know that list <function> can be used to list the code of a function you want to examine. You must know that break 72 will set a breakpoint on line 72. That continue will let the code resume executing until it hits the next breakpoint. A developer uses IDE double-click on the line they want and uses an icon to step through or continue executing code.

Knowing the low-level details seems like it’s a pain, but it’s what helps build expertise. The need to know the details helps a developer understand what the IDE tools are doing. After all, the IDE is abstracting out the commands used to fulfill a purpose. A developer learns their tools when they work with them at the command level. I often recommend to teams that new developers use their terminal first while they learn, and only after they become proficient do they move to tools that abstract the details. At that point, they then understand what their tools are doing for them and how to leverage them best.

Another great reason to use the terminal is that you can script or create make files to accomplish a series of activities that otherwise would be difficult to do in an IDE. In addition, embedded developers are starting to leverage modern software tools like unit test harnesses, Docker, and DevOps pipelines. But, again, these capabilities are best developed and managed from the terminal command line.

Why Should Developers Use an IDE?

An IDE provides a single place for a developer to go to perform a wide variety of activities. For example, if you look at the Eclipse IDE, a developer can perform activities such as:

  • Checking out and committing code to a repository
  • Writing/editing code
  • Compiling
  • Debugging
  • Application Configuration management
  • Target memory examination
  • Etc.

The list goes on and on. A developer can perform nearly any activity they might need to do to develop and test their software from one application. Honestly, this is awesome.

An IDE is great for an inexperienced developer. Complex commands and features are often abstracted through the IDE's graphical user interface (GUI). That means inexperienced developers can be productive sooner than later because they don’t need to know or understand the lower-level details. A developer clicks the debug button, and magic happens to compile, load, and run the application on the target.

An IDE can be beneficial, but they aren’t all roses and rainbows. I’ve seen developers and teams occasionally fall into IDE traps. First, if a team isn’t careful, they may become IDE-dependent. All those abstract details can be lost, making it difficult for the developer to move forward if they are forced to use the terminal. Second, with continuous deployment of software today, I’ve seen issues with plug-in incompatibilities and feature additions that break IDE capabilities. So while an IDE can keep you using the latest and greatest, sometimes that isn’t exactly what you want.

Should You Use a Terminal or IDE?

Yes! Great embedded software developers and teams know that you need to use both in today’s development environments! IDEs simplify debugging processes and often provide great text editing capabilities. Trying to debug from a terminal using GDB is possible; I’ve done it, but using an IDE that abstracts out the low-level commands for setting breakpoints and navigating the code is much easier. The IDE can dramatically simplify activities that are just cumbersome from a terminal.

The terminal is also critical to use. I often use the terminal to manage my Docker images, build code, manage my Git repo, run unit tests, and perform various other activities. Of course, some activities could be done from the IDE, but I find that using the terminal at least occasionally helps me keep sight of the low-level details and prevents becoming too IDE dependent. It’s not uncommon to find me with an IDE and the terminal open together and doing activities in both!

Conclusions

When deciding between using the terminal or an IDE, the best solution is to balance a little bit of both. IDEs provide great capabilities and tools to embedded developers that are slow and unwieldy to use in a terminal. Terminals help provide fine-grain control over tools and development environments often abstracted by the IDE. It’s not a question of using one or the other; it’s a question of how to utilize each to best achieve your goals.

Hide comments
account-default-image

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish