Live data from Hacker News

Ask HN: Reasonable Java editor for heavily CLI-oriented UNIX types who hate bloat?

news.ycombinator.com

31–40 of 53 posts

Re: Ask HN: Reasonable Java editor for heavily CLI-oriented UNIX types who hate bloat?

#31
post #5

it seems really weird to me you find netbeans complicated. There's a reason java developers use bloated IDE's for anything more than quick edits. Spend a week in Netbeans and I bet you a lap dance you keep using it.

I'll second that. As a seasoned eclipse user I had another look at Netbeans recently. It seemed pretty much the same for me, and offered no compelling reason to switch. Until I poked around the profiler.

Well, let me say there's no going back for me. The Netbeans profiler gives me confidence from knowing exactly what my application is doing, and exactly what that third-party library is costing me. The coverage, allocation stack traces, and jvm heap monitoring are fantastic. Seriously. Take a look: http://www.netbeans.org/kb/60/java/profiler-intro.html

So yeah, I'll take a slice of that action and throw a pole dance in on that lap dance you bet. And it didn't even take me a week before I realised.

Re: Ask HN: Reasonable Java editor for heavily CLI-oriented UNIX types who hate bloat?

#32
post #31
post #5

it seems really weird to me you find netbeans complicated. There's a reason java developers use bloated IDE's for anything more than quick edits. Spend a week in Netbeans and I bet you a lap dance you keep using it.

I'll second that. As a seasoned eclipse user I had another look at Netbeans recently. It seemed pretty much the same for me, and offered no compelling reason to switch. Until I poked around the profiler. Well, let me say there's no going back for me. The Netbeans profiler gives me confidence from knowing exactly what my application is doing, and exactly what that third-party library is costing me. The coverage, alloc…

If you jumped from Eclipse to NetBeans, there wasn't any pain from the different plugin offerings? I don't enjoy installing two IDEs for the same language, but that's what I end up doing, unhappily.

Re: Ask HN: Reasonable Java editor for heavily CLI-oriented UNIX types who hate bloat?

#34

Earlier quoted context omitted.

All right. So, what if I have an existing project I want to import into Eclipse and not have it lay its workspace droppings all over it? Can I do that and leave the actual source tree relatively untouched? What happens when I want to export it out of the workspace back into the external form the tree took before?

You mention Vi, but as an Emacs user one of the things that eased the transition to Eclipse for me was a setting that enabled all of the commands I already knew (google emacs mode). Also Eclipse has a great set of keyboard shortcuts to do everything, I normally do my whole workflow without the mouse being on my desk. For Java work an IDE is essential. For C/C++ I still use Emacs but having Javadocs integrated right t…

Eclipse's emacs mode is nothing like Emacs. For example, it binds undo to F9, leaving C-/ (the emacs binding for undo) as "comment this line". WTF. Of course, once you fix the bindings, Eclipse's undo doesn't work anything like Emacs' undo. It's not Emacs, it's Eclipse with C-a (but not M-n) and C-e.

Re: Ask HN: Reasonable Java editor for heavily CLI-oriented UNIX types who hate bloat?

#35
post #11
post #8

I get funny looks for using emacs for Java work, but it loads and runs fast on all the different platforms I work on. I have used and support people using Eclipse, and generally I like the ability to find definitions etc, but the refactoring rarely proves essential. As for autocompletion, if you can't hold the whole core language in your head, there's something wrong somewhere ;-)

I think if you find that refactoring is "barely essential" then you are really missing out. I must use it's features about 20 times a day - from simple ones like "Rename" (seriously how would you do that easily in emacs, when the class is used in 15 places?), Extract Local Variable, Extract Method, etc.

I don't do multi-file changes in emacs, but they are pretty trivial with "perl -pi -e ...". You have a lot more flexibility with this method. I often create a new branch, spend a few commits getting the rename right, and then squash the commits and apply it to my real branch. (Sometimes I apply the changes to the index instead of applying it as a commit -- this way I can change other things in the same commit.)

Anyway, the automated tools sort of fake this workflow, but sometimes the real thing is nicer.

Re: Ask HN: Reasonable Java editor for heavily CLI-oriented UNIX types who hate bloat?

#36
post #31

Earlier quoted context omitted.

I'll second that. As a seasoned eclipse user I had another look at Netbeans recently. It seemed pretty much the same for me, and offered no compelling reason to switch. Until I poked around the profiler. Well, let me say there's no going back for me. The Netbeans profiler gives me confidence from knowing exactly what my application is doing, and exactly what that third-party library is costing me. The coverage, alloc…

If you jumped from Eclipse to NetBeans, there wasn't any pain from the different plugin offerings? I don't enjoy installing two IDEs for the same language, but that's what I end up doing, unhappily.

No pain at all. I don't rely heavily on plugins though. The important bases were covered: refactoring, vcs integration, and the usual javadoc/outlining.

Perhaps the only things I missed were getting a method's signature when you hover over it with the mouse, and the live variable value when you hover in debug mode. But these are so minor that I feel if they're not already there and I somehow haven't set them up, they'll be in the next release. But as I said, I get so much more confidence by being able to charge in to my code's runtime and poke around that it's worth it.

Re: Ask HN: Reasonable Java editor for heavily CLI-oriented UNIX types who hate bloat?

#37
post #13

ablashov, I have to chime in with the others here and let you know that Eclipse does so many things for you, that in direct contradiction to what you assume, it is actually difficult to set up Emacs or Vi to do the same for you. One example is whole-workspace refactoring : Let's say you decide that a function (method) needs to take an extra parameter, a boolean, but actually, that is just to cover some corner cases,…

I'll go further and say that Java is a horrible experience without Eclipse. One of my colleagues at work said today that (1) Java sucks without Eclipse and (2) Eclipse's wonderful features wouldn't be possible without all the things that makes the Java language suck.

That is Seibel's corrollary to Greenspun's Tenth Rule, no? Every sufficiently complex java program need a programmable IDE to make up for the half of Common Lisp not reimplemented in the program itself.

Re: Ask HN: Reasonable Java editor for heavily CLI-oriented UNIX types who hate bloat?

#38
post #8

I get funny looks for using emacs for Java work, but it loads and runs fast on all the different platforms I work on. I have used and support people using Eclipse, and generally I like the ability to find definitions etc, but the refactoring rarely proves essential. As for autocompletion, if you can't hold the whole core language in your head, there's something wrong somewhere ;-)

The java language is actually very small and easy to remember. The standard library, on the other hand, is huge. If there's any glory in remembering what the constructor arguments are for a certain class, it's lost on me. Plus, in the real world, many of us use what we call "third party code" which could be as simple as something as a database driver or some kind of utility class. If you think you're going to remembe…

> In your world, you spend a week doing it and probably typing javac over and over on the command line.

Perhaps you should learn to use the command line if you think refactoring without an IDE takes a week. :-/

Re: Ask HN: Reasonable Java editor for heavily CLI-oriented UNIX types who hate bloat?

#39
post #11

Earlier quoted context omitted.

I think if you find that refactoring is "barely essential" then you are really missing out. I must use it's features about 20 times a day - from simple ones like "Rename" (seriously how would you do that easily in emacs, when the class is used in 15 places?), Extract Local Variable, Extract Method, etc.

I don't do multi-file changes in emacs, but they are pretty trivial with "perl -pi -e ...". You have a lot more flexibility with this method. I often create a new branch, spend a few commits getting the rename right, and then squash the commits and apply it to my real branch. (Sometimes I apply the changes to the index instead of applying it as a commit -- this way I can change other things in the same commit.) Anywa…

I've always had this nagging suspicion that I could become more productive, if only I truly learned how to use emacs. But this post has just finally convinced me that the only people who cling to emacs for large scale development are true believers who will never be swayed.

The automated tools don't fake your workflow. A refactoring tool performs code modifications that it can prove make no change to the semantics of the code. You can sort of fake this, in a painful way using perl, but as you've just stated, your system is so unreliable that you create a branch to do something I may do a dozen times in an hour when I have some time to go back and clean up.

Re: Ask HN: Reasonable Java editor for heavily CLI-oriented UNIX types who hate bloat?

#40

Anybody who writes java code in anything outside of Eclipse, NetBeans or IntelliJ is wasting their time. It doesn't take an enormous amount of time to learn how to use Eclipse. It probably takes 15 minutes of someone showing you the ropes. You need to stop thinking of the problem as "I need a text editor" because that's almost certainly not what you need. Eclipse in particular does nothing like what you claim ("unnec…

I agree 100%. On java projects, I don't consider myself a "java developer" because frankly, writing java in unsupported editors is a pain in the ass. I couldn't imagine writing java code with Eclipse. It would be an order of magnitude less efficient.
Post reply on HN