[dasil003]

This is very eloquent distillation of the thought process underlying the evolution of my toolset over the last 5 years.

After having jumped into Rails and shifting from BBEdit to TextMate as my primary editor overnight back in 2005, when TextMate started withering on the vine I became disillusioned that I had put so much effort into pursuing such a short-lived tool.

Reflecting on my history with a UNIX shell going back to the late 80s, I realized that things I had learned 10, 20 years ago from the UNIX world were still relevant today. I committed myself to getting serious about vim because I want to optimize for A) learning many programming languages and B) not using verbose Java-like languages that require IDEs for the all the boilerplate and rote refactoring.

While this kind of toolset will never provide quite the bang for the buck of a contextual IDE in a specific language, it's a phenomenal hedge against all the career risks I face in terms of Ruby becoming irrelevant, the web becoming irrelevant, Apple nerfing OS X, or any other probable sea change. No matter what happens I feel like vim + bash will bring me an immediate level of productivity in any new task I face, even if I start flattening out before I reach the Eclipse or Visual Studio level of wizardry, I don't expect any one thing to last long enough in this industry for such optimizations to pay off.

[SoftwareMaven]

Very similar to my view of Emacs. It doesn't matter whether I'm on my Mac, my work Ubuntu, or SSHed into a Debian server, my development environment is the same. With Cygwin, I can even make it work on Windows (heaven forbid! ;). It is nice to have the biggest context change be "where is my source here?"

[jfb]

Emacs runs native on Windows; no need for Cygwin.

[SoftwareMaven]

Of course, but a reasonable chunk of my development work happens in shells. It continues to shrink over time, but there are a lot of things pipes can handle better than lisp. :) I would be lost without it.

[laureny]

> not using verbose Java-like languages that require IDEs for the all the boilerplate and rote refactoring.

You probably need to revisit your opinion on IDE's, they haven't been used for boiler plate code since the late 90's with Visual Studio.

Java IDE's make your more productive and they help you keep your code base in a healthy state with very little technical debt. Not using them would be like preferring a screwdriver over a drill.

[gizmo686]

My understanding of dasil003's point is that it is not a complaint about IDEs, but rather about languages that are designed in such a way as to require IDEs. For example, in Java, if you want to sort a List by a given field (using the Native Collections.sort method), you would need to do something like:

Collections.sort(myList, new new Comparator<E>() { public int compare(E o1, E o2) { return 01.val-02.val } }

(You could also make your class implement Comparable, but then you need to own the class, have only one ordering used in the entire program, not mind making the ordering a property of the class).

If you are in an IDE, then writing all that out is not to bad because of auto complete. If you are stuck in a plain-text editor, you would much prefer something like: Collections.sort(myList, lambda<E->int> x->x.val);

Java 8 does incluse lambda's, so maybe this particlar case has been solved. But languages with a strong CLI pressense in the community tend to need alot less IDE than languages with a strong IDE pressense in the community.

[gchpaco]

Another way of looking at this is how much code you have to read. This is one of the reasons I hate wizard generated code in a way that I don't hate InterfaceBuilder or similar serialized object trees. If I'm gonna have to read the code eventually, the fact that your IDE makes it easy to draw a button is cold comfort to me when it takes 100 lines of cryptic C to do it (actually pretty common in early Windows programs or Xaw hacks, but mercifully diminished in frequency in these more enlightened days).

Code generation can cause people to neglect library design; the reason why the MFC wizards spat out volumes of code instead of calling a library method is because you might need to rewrite some or all of that. You are not expected to modify InterfaceBuilder output, nor should you have to any more than you would have to regularly rewrite bits of Xlib to customize them appropriately.

[dasil003]

This is correct, I just don't like Java. IDEs are really beside the point; but the fact is there is no IDE that supports the breadth of languages that vim or emacs support. And there's certainly no IDE that I would want to run over SSH to machines spanning oceans, whereas vim copes incredibly well.

[eru]

I used to be in the same camp about not using languages that require an IDE. But I have recently started using something akin to a Haskell IDE, and I have to say, things like displaying the inferred types of expressions in a tooltip and jump-to-definition are nice to have.

[mattmanser]

I don't use Java but the equivalent in C# is literally `thing.OrderBy(p => p.Whatever);`. So even simpler than your example.

The boiler plate code has been disappearing in C# a lot faster than Java, but I believe Java is catching up.

So needing an IDE to actually edit code to relieve the tedium of boilerplate is is not the case these days, although you still need it to manage things like references, I'd not want to manage that myself.

[dasil003]

> Java IDE's make your more productive and they help you keep your code base in a healthy state with very little technical debt. Not using them would be like preferring a screwdriver over a drill.

All analagies suck, but let me just refine this one by saying that the unix philosophy is like preferring a toolbox with a screwdriver, a wrench, a saw, a hammer and other simple tools vs a power drill—the power drill is great for driving screws but it's completely useless for other tasks, and it won't necessarily fit into tight spaces that a small screwdriver would.

[krickle]

No, IDEs make you more productive. It's like declaring that your blue screwdriver is better than their red screwdriver.

[kamaal]

I think much of Java programming we are talking of today is basically using the IDE.

Opening a file and reading from it takes tens of lines in Java, and that's just a trivial task. Stuff like that is better left auto generated.

You don't learn Java these days, you just learn eclipse. Much of the magic is happening in auto complete. I am not sure who picks up a book to learn java these days.

[irahul]

> Opening a file and reading from it takes tens of lines in Java,

Some of the bad Java is because of missing abstractions, most of it is because of badly designed api.

http://paulbuchheit.blogspot.in/2007/05/amazingly-bad-apis.h...

For your particular example, the api has been better since Java 5.

    import java.util.Scanner;
    import java.io.*;

    
    public class ScannerTest {
        public static void main(String[] args) throws FileNotFoundException {
            Scanner in = new Scanner(new File("some_file"));
            while (in.hasNextLine()) {
                System.out.println(in.nextLine());
            }
        }
    }

> You don't learn Java these days, you just learn eclipse. Much of the magic is happening in auto complete.

I code in vim with eclim. There is nothing to be gained by manually writing the code for getter setter, or find-replace an identifier, or write placeholders for n methods of an interface...

> I am not sure who picks up a book to learn java these days.

It was some time ago(about 8 years ago), but I learned Java from a book(multiple books; I liked Core Java best http://www.amazon.com/Core-Java-Volume-I-Fundamentals-Editio...)

Also, what good would eclipse do to someone who doesn't know what to write? Consider my example above. Unless you know how to read a file, how can eclipse generate the code for you?

Or consider generics. How will eclipse help you understand what does <T extends Comparable<? super T>> mean? Eclipse is an aide. Unless you understand the language well, it doesn't help.

[lucian1900]

> I code in vim with eclim. There is nothing to be gained by manually writing the code for getter setter, or find-replace an identifier, or write placeholders for n methods of an interface...

None of which is necessary in better languages. I believe that was the parent's point.

[irahul]

> None of which is necessary in better languages.

It isn't necessary in any language, but it sure is useful.

I don't know what you mean by better languages, but I program comfortably in variety of languages(Ruby, Python, C, C++, Java, Clojure, Lua, Racket, go, JS, perl...) and haven't found a single language in which context aware auto-complete, assisted re-factoring, looking up inline documentation etc isn't useful.

[lucian1900]

Generating get/set and abstract method bodies is only necessary in Java.

Find-and-replace, auto-complete and docs are of course useful generally.

[spc476]

I'm reminded of The IDE Devide (http://osteele.com/posts/2004/11/ides), which describes the differences between a "langauge maven" (which I'll admit to being) and a "tool maven".

[cageface]

Is switching tools really so catastrophic? I have emacs keybindings burned into my muscle memory but just about every tool I use supports them.

But if I'd insisted on sticking with Emacs instead of moving in the mainstream (Xcode & IntelliJ for mobile) I would have ultimately been much less productive than I've been after spending a week getting my head around more specialized tools.

[mceachen]

This is exactly how I approach new tools.

My brain-stem knows what to type when I want to go to the end of the line. If the tool doesn't do what I expect when I hit that keystroke, I update the keymapping. In about 1 hour of coding/retraining, the keymap works quite well.

[djhworld]

This is the approach I've taken, I use Vim keybindings in IntelliJ and use Vim for lightweight stuff/text editing when required

Best of both worlds

[adventureloop]

Switching tools isn't a problem if you can massage tools to be a similar as possible.

I install a vi plugin anywhere I can. Most of the time this bridges my mental gap. There is nothing worse than a half working vi plugin though.

[jasonm23]

Thank you for this "when TextMate started withering on the vine I became disillusioned that I had put so much effort into pursuing such a short-lived tool."