The IDE as a Bad Programming Language Enabler
For many years, I've found myself frustrated with the tools of various
programming languages, primarily IDEs, previously with Java, currently
"In the beginning" I used to use a simple text-editor, like Emacs and later JEdit. Finally in 2004 I converted to Eclipse for Java development, an uneasy relationship that fell apart in 2008 when I moved to IntelliJ after trying out NetBeans for a while. In the last year, my relationship with IntelliJ has fallen apart when it comes to Scala development, as it seems IntelliJ is unable to keep up with syntax that is more functional in nature in general, and use of Scalaz in particular.
Being curious, I've also done quite a bit of Clojure development in the
last year, and also started to dabble more seriously with Haskell.
These two wonderful languages have taught me one thing: if the language
is good enough, an IDE is strictly not needed as long as you have good
support for syntax highlighting and parens matching in the case of
clojure, or indentation in the case of Haskell.
In the case of Scala, I don't think an IDE is required either, provided you can reign in your bad habits in terms of source organization from Java.
IDE's as Code Navigators
In Java-land, IDEs are absolutely required for a number of reasons, not least because Java is verbose, has a high "tap the keyboard-to-though"-ratio and is generally clunky. But furthermore, because a combination of shortcomings in the Java compiler and Javas OO nature, we end up with lots and lots of small files for every interface and class in our system. On any less than trivial Java system, development quickly turns into a game of code- and file-system nagivation rather than programming and code editing. This nature of Java development requires IDE's to become navigation tools above all.
In functional programming, without Java's code organizational patterns however, there is nothing forcing us to scatter our functionality across hundreds and thousands of tiny files. We can think in terms of namespaces instead, and there is absolutely nothing wrong with having quite a few funtions and data types in a single namespace as long as they seem to be relatively related. If we think about our FP code in this manner instead, the requirement for a 200mb download of a code navigator like Eclipse or IDEA becomes a lot less important. All of a sudden, it becomes very easy "to get by" with something like Emacs, which is still a superior text- and code editor to anything out there.
What About the Other Things IDEs Do?
Of course there are many other things that IDE's do, like allow for running individual tests, refactor, code complete etc. However, with a good REPL and a good build tool, these things are not only not needed, they quickly become the inferior tools. What's quicker, running an individual Scala test in IDEA or running continuous compilation/testing in SBT? SBT will win every time. What's better, experimenting in your IDE or on a REPL? A REPL will win hands down every time.
Conclusion: A Need For IDEs Is a Language Smell
I've been programming since I was 7 years old. My short foray with
IDE's (in perspective: 2004-2011/2012) also coincide with my most
frustrated period with tooling and languages. I don't think this is a
coincidence. Comparing using poor languages (..ehm, Java)requiring
tank-like IDE's, with using a more lightweight toolchain with sane
languages like Haskell, Clojure and Scala (used correctly) only confirms
I can only conclude that the need for an IDE or a heavy "code navigation tool" is a symptom of a deeper problem, if you suffer from tool frustration, it's not necessary your tools that are poor, it may be that your language sucks, or you're not using it correctly.
Edit: Defining IDE vs Editor
It might be worth definining "IDE vs editor": what I primarily turn
against in this post is languages and the complexity in them that
necessitate the use massive monolothic IDE's like IntelliJ IDEA, Eclipse
and Visual Studio.
I don't include editors such as Emacs, Vi/Vim, Sublime Text 2 etc in the "IDE" - I think the approach taken by these editors in their "language awareness" is good in that they piggyback on existing infrastructure such as REPL's, build systems etc, instead of trying to re-implement large parts of it, or supplement the lack thereof as is the case with IDEs in Javaland.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)