Live data from Hacker News

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

news.ycombinator.com

41–50 of 53 posts

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

#41
post #15

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'm the complete opposite of the OP. My intro CS courses were taught using Eclipse, and I am constantly using it (for lack of a better, free, option) at work. I am getting more and more fed up with the bloat in Eclipse. Running in a Linux environment results in hard-to-diagnose crashes fairly often, and the memory overhead is, quite frankly, unacceptable. I would gladly move to something lightweight like the OP asked…

Note that the argument isn't that Eclipse [1] is perfect, but that Java without Eclipse is impractical.

[1] Or some other rich IDE.

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

#42

Earlier quoted context omitted.

First of all: you are using version control, right? Please tell me yes. Eclipse isn't going to "change" your code at all. It'll put two or three files and dirs in the root of your project. That's it. Your code is the same as it was before.

Yep, using SVN. Not sure I want Eclipse to ride it, though.

If you move a class to another package in Eclipse (using drag&drop), it will automatically issue the necessary svn move command, and synch up the import statements everywhere. That's a 20 minute job done in 2 seconds.

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

#43
post #7

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 have to second this. If you are building anything more complex than a very simple project, and you are not using one of the three (Eclipse, Netbeans, Intellij) -- you are wasting a lot of your time. They are not hard to learn. The stuff you lose in a simple text editor: refactoring support, integration with version control, code-complete, debugging...etc. I'm simply going to guess based on your post that you also d…

The only problem of course is that when your "more complex than a very simple project" hits the size where Eclipse just can't take it any more. A project I'm working on is pretty much at that scale, and random things basically stop working if I so much as stop looking at them. Its quite amazing.

I've heard from coworkers that IntelliJ could handle it, but at the cost of agonizing slowness. So now I fire up eclipse (and reset all my project options and input from scratch) only when I need refactoring, and use emacs otherwise. Its not great, but at least I don't swear all day long.

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

#44
post #7

Earlier quoted context omitted.

I have to second this. If you are building anything more complex than a very simple project, and you are not using one of the three (Eclipse, Netbeans, Intellij) -- you are wasting a lot of your time. They are not hard to learn. The stuff you lose in a simple text editor: refactoring support, integration with version control, code-complete, debugging...etc. I'm simply going to guess based on your post that you also d…

The only problem of course is that when your "more complex than a very simple project" hits the size where Eclipse just can't take it any more. A project I'm working on is pretty much at that scale, and random things basically stop working if I so much as stop looking at them. Its quite amazing. I've heard from coworkers that IntelliJ could handle it, but at the cost of agonizing slowness. So now I fire up eclipse (a…

What size projects are you using?

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

#45

Earlier quoted context omitted.

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…

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.

Yes, judge thousands of people by one person. That has served society very well over the years.

Anyway, in Eclipse, every non-trivial rename "requires preivew" and often requires cleanup. If you just want to change the name of a class, the GUI is fine. If you want to do something more involved, you end up doing it manually anyway.

For trivial renames in Emacs, I have a function called "rename-this" which is mode-sensitive and Does The Right Thing for languages I actually use (Perl, Haskell, and Lisp). (Most things are non-trivial, though, as dependencies on a class name are not always in the form of the class name in the source code. "${prefix}::Foo" is hard to detect, but occasionally appears. Refactoring works well in Java because there is no possibility for syntactic abstraction, and it must be a function of your text editor. That approach is why I avoid Java.)

Edit: BTW, if you get to make a snide comment, so do I:

"Your post has finally convinced me that the only people who cling to IDEs for large-scale development are true believers who are more comfortable clicking buttons than writing software." Tool building is an important skill that IDEs actively discourage.

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

#46

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 have to second whirly's opinion. When you are writing some rather complex java, eclipse gives you the following:

- Enforce code style (eg: checkstyle plugin) and source formatting rules - Project Management - Java code autocompletion (works perfectly like 99% of the time) - XML autocompletion through dtd - With some plugins you get autocompletion for jsp, etc - Hard-Core refactoring (you've got an example from another guy) - VCS integration (git, mercurial, svn, even vss, you name it) - I tend to prefer to use git or mercurial from the commandline, but eclipse has a nice merge editor and it lets me compare 2 commits very very easily. The Hg plugin even shows a tree graph with the commit tree - And lots of lots of plugins (the mylyn and jira/bugzilla/trac connectors are really nice for example)

My main argument is that it's so much easier to inspect for example a class in a jar library and see the methods it implements within eclipse/intellij/netbeans than with any other plain text editor. Eclipse even lets you see the javadoc for the class.

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

#47
post #7

Earlier quoted context omitted.

I have to second this. If you are building anything more complex than a very simple project, and you are not using one of the three (Eclipse, Netbeans, Intellij) -- you are wasting a lot of your time. They are not hard to learn. The stuff you lose in a simple text editor: refactoring support, integration with version control, code-complete, debugging...etc. I'm simply going to guess based on your post that you also d…

The only problem of course is that when your "more complex than a very simple project" hits the size where Eclipse just can't take it any more. A project I'm working on is pretty much at that scale, and random things basically stop working if I so much as stop looking at them. Its quite amazing. I've heard from coworkers that IntelliJ could handle it, but at the cost of agonizing slowness. So now I fire up eclipse (a…

> So now I fire up eclipse (and reset all my project options and input from scratch) only when I need refactoring

That seems a pretty sensible approach in any case. Emacs is just a nicer environment to live in for day to day editing.

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

#48
I was in the same situation a while ago and ended up jumping to netbeans with the free and excellent jvi plugin. However, I feel your pain and when I recently started using scala on a hobby project I was really happy to be able to just use vim again -- partly because the netbeans support isn't so good for scala and partly because the language "feels" like it doesn't need an IDE.

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

#50
post #37

Earlier quoted context omitted.

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.

I had a conversation about refactoring with one of the giants of the Lisp world earlier this week about this, actually. The parts that make Lisp so powerful are the parts that also make it so hard to build reliable refactoring tools. Refactoring is something you need in any language. Otherwise, the implicit presumption is that you always get your software architecture 100% right the first time around.
Post reply on HN