Wille Faler is an experienced software developer, architect and agile coach with experience across a number of different industries as an independent consultant. Wille specializes in backend, integration, and Java technologies, but has more recently found a passion for Scala and text mining/analysis. Wille is a DZone MVB and is not an employee of DZone and has posted 39 posts at DZone. You can read more from them at their website. View Full User Profile

The IDE as a Bad Programming Language Enabler

  • submit to reddit

For many years, I've found myself frustrated with the tools of various programming languages, primarily IDEs, previously with Java, currently with Scala.

"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 this.
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.

Published at DZone with permission of Wille Faler, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Karl Peterbauer replied on Wed, 2012/10/31 - 3:21am


1. Efficient code navigation ("Go to source", "Go to declaration", "Go to superclass", "Find usages", ...) is the most valuable tool for working with a larger codebase, independent of the language (which is hopefully supporting precise navigation).

Trying to understand thousands lines of code written by somebody else (or by you a few years ago) without code navigation is like researching a certain subject on the web without hyperlinks.

2. Refactoring is an important part of our daily business (again independent of the language). Like it or not, but things (requirements, business processes) change over time. Refactoring without proper IDE support (and "Find usages") is error-prone, tedious and a waste of time. 

3. The need for an IDE for code navigation and refactoring is not Language Smell. The need for  REPL is bad smell. A decent developer using a decent language does not need to check out each and every LOC while typing.

André Pankraz replied on Wed, 2012/10/31 - 8:00am


Haskell, Clojure, REPL, Emacs - programming hipster, yey - you missed NoSQL.

Write Business Apps with >50k lines of code and lots of libs-provided functionallity (like PDF export, reliable messaging, persistent processes etc.) and we speak again.

Look at something like this Haskell Session...https://www.youtube.com/watch?v=7Wmszk4wZxQ  ...what he does from minute 2:00 to 3:00 - that must be like programming without an IDE - lol


Justin Simonelis replied on Wed, 2012/10/31 - 8:41am

 This is the stupidest article I have read in ages!!

I completely agree with commenter Karl Peterbauer. I am a HUGE fan of auto refactoring. These features are worth their weight in gold. You just don't get advanced refactoring capabilities in text editors. Being able to quickly navigate code is hugely important to understanding and efficiency. 

Dzone needs some QA.

Mark Unknown replied on Wed, 2012/10/31 - 2:59pm

If you don't need an IDE you are:

1. A god (I am glad you can remember all the APIs)

2. Moving the complexity elsewhere (i.e. duplicate code   or using a difficult to use language)

3. Doing very simple things (i.e. writing a short script)

Dino VV replied on Wed, 2012/10/31 - 6:08pm

I would argue the opposite. IDE helps with learning a new language, write better code (e.g Idea with intentions), enforce standards, recognize duplicate code,  complex refractorings, generate template unit test code. debug code, browse code easily etc.

Christian Kulen... replied on Wed, 2012/10/31 - 6:14pm

IDE = Intelligent development environment ;)

Is using a GUI an application smell? Code generation features might reinforce boilerplate code that is also exposed to the programmer, but without code generation features, you will hide the boilerplate code behind some language features or complex library functions. This is about scope and not about smell.

Jammer Man replied on Thu, 2012/11/01 - 2:13pm

What a dumb and pointless article.  +1 to Karl, btw.

Jose Maria Arranz replied on Fri, 2012/11/02 - 3:48am in response to: Karl Peterbauer

Karl, how can I change the color of your comment to gold?

Liam Knox replied on Fri, 2012/11/02 - 6:39am

Don't think there is anything wrong with REPL's. They certainly have a development place.  But this article is clearly just complete and utter nonsense

Loren Kratzke replied on Fri, 2012/11/02 - 7:17pm

 To Karl's list I would add: Debugging, Profiling, VCS (checkout, commit, changes, diffs, history, patches, etc), container management (Tomcat, Glassfish, etc), DB clients, Maven repo browsers, Issue trackers, JVM management, log tails, project templates, and about a half dozen other things that my Netbeans IDE puts at my finger tips. Seriously, you will have to pry my IDE out of my cold dead hands.

Lund Wolfe replied on Sat, 2012/11/03 - 10:38pm

Tools are not overrated.  You need an IDE for real world apps.  Otherwise, you are doing everything manually yourself with little time left to do or enjoy programming.

I'll make an exception for someone just learning to program or learning a language.  The more they have to do and know about the whole language development process, the more comprehensive understanding and power they will have.

A Jones replied on Mon, 2012/11/05 - 10:08am

As somebody who is writing a ~50k LOC business application, I do not use an IDE. Allow me to explain why...

Code completion is unnecessary as I have word completion (I can tab anything that's been typed before) and a decent memory. On the latter point, I find that there are many hidden benefits to keeping the code in your head as opposed to your IDE. You understand the architecture on the big picture scale intuitively and can balance new requirements against what is there in an efficient manner. This is not possible if all you ever see is one source file at a time and try to keep the code out of your head and in the computer.

"Go to source", "go to definition" are completely unnecessary if you know how to use grep. Groking grep gives you a tonne of benefits as a side effect (i.e. being able to find anything. Including the meaning of life.)

Refactoring tools are completely unnecessary if you know how to use sed.

My personal take on this is that every couple of generations the new kids decide that they want to do all the work that's previously been done again. This time better, shinier and better! In this process, they come up with shiny tools which are easy to use. Then you start to dig into them and see that that ease of use is about the only benefit. For moderately complex tasks or ones which require something unusual, the tools become useless.

In conclusion, the IDE which nobody mentions and everyone desperately needs to learn is POSIX + Vim/Emacs. All other options are the effect of marketing doing their job and drilling needs into your head which you don't really need at all. Except Visual Studio, that was done nicely.

Loren Kratzke replied on Mon, 2012/11/05 - 4:22pm in response to: A Jones

 Interesting. So your code is fresh in your head, and you may or may not have 80 other developers working on your code base. Nice place to be but that it is not realistic to assume that will always be the case.

Code completion and word completion will give two very different results. My IDE's code completion is a context sensitive shortcut to Javadocs, something word completion simply can not do. And it gives you results that you have not yet typed. It does not rely upon your keyboard history to be useful, and that is when it is most useful.

String matching and source navigation are two entirely different things that yield different results. I don't want to know where "setName(" occurs, I want to know what calls the setName(String name) method, specifically this instance of the method because I may have dozens of methods with this signature. I would much prefer to rely upon results backed by static code analysis.

Search/replace is entirely different from refactoring and could lead to very disturbing results.

I don't doubt that you can be productive without an IDE, but the IDE is a productivity tool and you will eventually reach a tipping point where you will be far more productive using an IDE.

Come back when your code base is 15 years older, has had large portions written by other people (years before by people who no longer work there), has 500,000 lines of active code, and another 150,000 lines of deprecated and/or legacy code. Or simply start a new job where that is the case. Needless to say, I would not let you near my code base with your primitive tools. The effects could be disastrous. Search and replace text, I don't think so.

That said, I have worked with your type before. Usually they eventually switch to using an IDE because they realize that it is a tool and not a crutch, and there is no compelling reason not to switch, and several compelling reasons to switch.

Justin Simonelis replied on Mon, 2012/11/05 - 4:36pm

A Jones: 

Come back to earth.

Mark Unknown replied on Mon, 2012/11/05 - 7:14pm in response to: Loren Kratzke

+1 to Loren. I have stood behind people like A. Jones and think, if you just used an IDE you could cut out half that typing. And to top it off, they end up recreating an IDE with all the scripts, etc.  If you are just working on opensource, have at it. But if you are working for someone else, they are not paying you to create an IDE nor prove how much of a coding god you are. Unless you ARE writing an IDE or in a contest to prove your deity-ness.  

Karl Peterbauer replied on Tue, 2012/11/06 - 1:58am in response to: A Jones

vim, emacs, grep, sed etc. are tools for manipulating text on the basis of regular expressions. Compilers and IDE's are operating on the level of syntactical grammar rules. A developer with your mileage should actually realize the fundamental difference (which has nothing to do with "news kids deciding that they want do all work again" or "marketing drilling needs into your head").

Karl Peterbauer replied on Tue, 2012/11/06 - 2:11am in response to: A Jones


Fabienne: Who's sed?

Butch: sed's dead, baby. sed's dead.

A Jones replied on Tue, 2012/11/06 - 4:55am

@Loren Kratzke

I've worked with your type too.

The difference is that one tool forces you to adapt to it's way of working while the other approach uses many tools which can be combined to achieve different things. 

In regards to code completion, you're supposed to read through the codebase to get familiar with it. That's how you find out about things you haven't typed. It also lets one read through the docblocks. It also does one better than code completion and reveals the architecture of the application as well as showing you the internals of components. The last point is important for the same reason that understanding how a computer works is useful for programmers - you need to know the terrain as well as how to walk it. The other benefit is that the "bus factor" is accounted for since more people know how a given piece of code works.

The purpose of static code analysis is to verify a program, not to provide code completion.

Search/replace is fine if you know your tools, your codebase and have a decent test suite for catching regressions. That last point is important - if you have good coverage then you should be able to make radical changes to the code without anything falling over. Hell, your tests should be able to catch errors introduced by a program which randomly changes characters in the source - what harm is a little search/replace going to do? 

That last technique is called Mutation Testing. It's a way of verifying that your tests are worth their salt.

It's one thing to think about the application in terms of the feature you're currently working on but it's a whole other level when you start considering the overall structure of it and how things fit together.

Christian Kulen... replied on Tue, 2012/11/06 - 1:10pm in response to: A Jones

Reading the codebase is also useful when you have all interesting tokens at your finger tips. Code completion adds information you would have to memorize/manually look up otherwise.

If there would be fast ant tasks or something similar that do things like refactoring or usage search etc. would you use them?

You actively decrease your working comfort and productivity to test the code coverage of your tests?

*edit: I accidently edited this back to a fromer version -.-

A Jones replied on Tue, 2012/11/06 - 1:01pm

I prefer to memorize - keeping all of that information "cached" is not as difficult as it seems. The brain is incredibly malleable and will adapt if you throw lots of information at it. Good nutrition is key to being able to do this. The sub/unconscious will then use that information to derive interesting data at unexpected times. E.g. you want to implement feature Z and suddenly remember that there's this really useful class in the system which will help.

I'm already using their equivalents in the form of CLI applications. They really are just as capable as anything else for getting the job done, with the added benefit of being scriptable and chainable. Not to mention that there are specialized tools for the job, e.g. http://iangreenleaf.github.com/Scisr/ - I just haven't encountered a pain point which would be solved with one yet and if it ain't broke, don't fix it.

I would quit/not take the job in the first place. In the case that there are no other options, I would starve and work on a startup product. If all else fails, I'd sell drugs to school kids. I kid, I kid. Dealing with those kinds of technical environments is simply not worth it. I've been there and the stress levels are through the roof. When you find yourself snapping at coworkers because of the unreasonable loads, you know it's time to move on. Sanity comes before money.

It seems uncomfortable from your perspective just as an IDE seems uncomfortable from mine. We're creatures of habit - this approach does not cost me any effort at this point, though the initial time investment was huge. Now I just think "I need to do X" and "things just happen". I don't need to try to remember anything because the system is adapted to my way of thinking. The intuitive action is invariably the correct one with such a setup.

It would be interesting to do a proper experiment comparing the styles since any claims of productivity are anecdotal at this point. I'm not saying this is the best approach for everyone but I did feel compelled to defend it as it's the best approach for some.

Christian Kulen... replied on Tue, 2012/11/06 - 1:28pm in response to: A Jones

I would quit my job instantly if I would have to use the tools of your liking. And I would fire everbody who would insist to use these tools (if I would be in a position to do so ;)). There is much better stuff to put into my brain than which methods and which classes are named in which way...

I think IDEs already have proven they are worth it... This is one of those cases where the argumentum ad populum is valid.

With an IDE I can work relaxed with all kinds of codebases.

Mark Unknown replied on Tue, 2012/11/06 - 1:42pm in response to: A Jones

You said " Except Visual Studio, that was done nicely." and "The difference is that one tool forces you to adapt to it's way of working while the other approach uses many tools which can be combined to achieve different things. " 

Of all the IDEs that I have used, Visual Studio is the only one that forces you "adapt to its way"." 

That being said, good IDEs (not VS) free me to do things differently because I can let that tool do what it was designed to do and focus on other things.  The "other approach", while it seems to free you, actually forces you to adapt to it's way of working (or "not" working)." 

"In regards to code completion, you're supposed to read through the codebase to get familiar with it". True. you should review APIs and available codebases (as needed). But that does not mean you should (or can) memorize them." 

"It's one thing to think about the application in terms of the feature you're currently working on but it's a whole other level when you start considering the overall structure of it and how things fit together."  I use an IDE, but still do this. Additionally, an IDE frees me up to think even more about my architecture."


Loren Kratzke replied on Tue, 2012/11/06 - 6:08pm in response to: Mark Unknown

 I totally agree. These people are usually great developers but they work too hard at proving that they don't need a better tool. It is an interesting case of techno-luddite. Using 1980's tools in 2012 for no apparent reason. It is as impressive as it is pointless.

A Jones replied on Wed, 2012/11/07 - 5:41am

These are not 1980's tools, they are under active development. All of the arguments presented thus far have been based on logical fallacies and smell like religious doctrine. Good day, gentlemen.

Robert Weissmann replied on Wed, 2012/11/07 - 7:00am in response to: Karl Peterbauer

Totaly aggree with Karl AND there are many more reasons to use an IDE. I guess the writer has never been working on large projects with different technologies and/or has no idea in how many directions an IDE supports your development (Tomcat/Glassfish/JBoss/ ... + tons more). A REPL might be usefull for some mini-tests but nothing else. Maybe the writer is expecting something like this, supporting more functional-style programming. Check this out : http://www.kickstarter.com/projects/ibdknox/light-table .

Mario Rabe replied on Wed, 2012/11/07 - 8:06am

I just have to backup A Jones a bit. I startet programming using an IDE, in fact Visual Age for Java, someone remembers? Thats before eclipse was developed. And I think I can say I am very familiar with eclipse and how to use it effectly.

However, the more exotic my projects were i found myself giving up more and more IDE features and falling back to more flexible tools.

How do you update IDs used in HTML as well as in Java-Code using refactoring? And you have to do that before Tapestry-/Wicket-/JSF-/Whatever-Plugin had its primetime?

In my opinion it is easier to use tools that always work very good instead of tools that work perfect often and make you a headache in the other cases. And you know what? It even happend to me that complex refactoring left my code uncompilable...

A word to clojure and emacs: it is so damn simple to get things done with that combi. I have doc-lookup, go to definition (and back) and so on right on board, without fuddling scripts. (Emacs does that for many langs, so why flaming it?)

I am working on a huge codebase rightnow and I find myself reusing large parts I never thought it would be possible and if I have to refactor some functions I can do so in place most of the time without even touching the callers!

Really, Java the Language complicates things, which has good sides (like static analysis), but bad sides too (like makeing it cumbersome to change)

Do it how you like it

Mark Unknown replied on Wed, 2012/11/07 - 11:23am in response to: A Jones

"All of the arguments presented thus far have been based on logical fallacies and smell like religious doctrine. "  Does that include all "arguements" or just those opposed to yours? :) 

Jonathan Chiocchio replied on Wed, 2012/11/07 - 4:01pm in response to: Justin Simonelis

I completely agree. The quality of the posts I've been reading lately here are shittier every week...for god's sake! 2012 and somebody's still doubting on whether IDE's are needed in real-life applications! clearly the guy that wrote this never needed to refactor a huge amount of classes or navigate some else's code, among many other dozens of things that justify (at least in Java) using an IDE...I have programmed in Haskell in academic projects and yet, I really missed an IDE...I wasted so much time typing (and fixes typos!), navigating things manually, etc...

Phuong Nguyen replied on Thu, 2012/11/08 - 1:06am

Lol, I just read the whole comments section and I disagreed with most of the counter-arguments.

If any one saying that without IDE they cannot refactor code or navigate where a method being used, declared, ….They are just wrong. I do that kind of stuff all the time in VIM and have never encountered a problem.

And if anyone saying that code completion in IDE is syntactic aware and context sensitive, I would just say it doesn't matter.

The unawareness of language syntactic allow a non-IDE editor to manipulate any kind of syntax,  either it's ruby, haml, html, python, objective C.

Beside, you cannot trust in an IDE (since it can be buggy and make mistake). Unit test is your friend. Run your test after you make change. Review the change before committing and you are good to go.

Karl Peterbauer replied on Thu, 2012/11/08 - 4:03am in response to: Phuong Nguyen

 Please enlighten me and show me how to rename a method with a globally non-unique name (like "getName()") and all of it's occurrences in VIM.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.