You’ve picked the language you want to learn, and you’ve learned more about the various language paradigms. You want to get started writing some actual code—but what tool do you use? With almost all languages, you can start writing code in any old text editor available to you, and that’s what programmers used to do, decades ago. Any good engineer, though, will find tools to make his or her job easier, and that’s where the Integrated Development Environment (IDE) comes into play. So now you need to learn how to use a tool before you can learn the language? Not necessarily. Although many programmers consider “should I use an IDE?” to be a question with an obvious answer, they don’t necessarily agree on what that answer is.
What’s an IDE, anyway?
In most cases, an IDE is a text editor with some extra bits added on to help you write code more easily. The text editor is at the core of the IDE, and works more or less like you’d expect. Many will highlight simple syntax errors on the fly, so you don’t have the experience of having a simple typo ruin hours of coding. They also often have an “autocomplete” feature, so that if you type system.math. and pause, the IDE will present you with a list of the various math functions available, so you don’t need to remember whether the square root function is sqrt() or squareroot().
Just about every IDE has a build automator of some kind that compiles the code, and builds an executable program by adding in any necessary libraries, some of which you may not even be aware of. Those same tools make it easier to organize and include any optional libraries, or ones you’ve created yourself.
The feature of most IDEs that you’d be spending the most time with, though, is the debugger. Depending on the IDE, it’s a suite of tools that will find errors in your code before it compiles, and then (hopefully) point them out to you so that you can fix them easily. That’s an oversimplification, and it’s far from foolproof: you’ll be swearing at the debugger for telling you that there’s a type mismatch on line 354 when the root of the problem is a logic error on line 256. But it’s a heck of a lot better than debugging by hand.
The Case Against IDEs
Now that you know what an IDE is, you want to run right out and get one? Not so fast; there are other sides to the argument. Depending on the language you want to learn, your choice of IDE may be quite limited, and the choices available might be fairly complicated applications. For example, if you want to use one of Microsoft’s .NET languages (C#, Visual Basic, or ASP.NET), you’re going to hear a lot about Visual Studio, which isn’t your only option, but it’s most common. The full version of Visual Studio is expensive, and has a lot more tools than a beginner needs, which is why Microsoft offers “light” versions for individual languages, free of charge, but even those can be pretty intimidating at first look.
You may also hear stories about “real programmers” who don’t use IDEs, but type all of their code perfectly the first time, from beginning to end, perhaps even in hexadecimal. Even if you don’t, you’ll probably hear from somebody who thinks that IDEs are overkill, and you can do everything you need with vi or emacs (which will then start an argument about whether vim or emacs add-ons constitute an IDE, and you don’t want any part of that; just back away slowly). Speaking very broadly, programmers who work in scripting languages, or languages that evolved from scripting languages, are more likely to regard an IDE as optional.
Your Fourth Grade Teacher’s Advice
For the very beginning learner, I think of it like using a pocket calculator. When you’re in the fourth grade, you learn to do long division by hand, but once you’ve mastered that skill, how often do you do it the hard way? You use a pocket calculator instead. Similarly, when you’re first learning, no matter what the language, it’s a good idea to be able to trace through the execution of the code by hand. You’re going to be generating lots of bugs, even in short programs, but you’ll learn a lot about your code by tracing through it on your own.
The programs you’ll be writing at this stage will generally be pretty short, and you won’t miss most of the features of a full IDE. You’ll be able to shorten the feedback loop between code and results if you don’t have to worry about a tool you’re not conversant with yet. The period before you’re ready for an IDE may be very short, a matter of days or weeks, depending on how quickly you’re learning. As a rule of thumb, once your code goes beyond one file, you should invest some time in learning an IDE.
Depending on the language, you may find it difficult to get any instructions on how to code without an IDE, or you may find the command-line interface for the compiler to be more obscure than a visual IDE. It’s worth noting that if you start by learning JavaScript, as I recommended in my first post in this series, all you need is a text editor and a browser, although you can certainly find JavaScript IDEs when you’re ready for them. The bottom line is that when you’re learning to program, the tool should be a help, not a roadblock.