Hacker News new | ask | show | jobs
by laureny 4895 days ago
> 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.

5 comments

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.

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.

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

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

No, IDEs make you more productive. It's like declaring that your blue screwdriver is better than their red screwdriver.
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.

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

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

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

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

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

"Generating get/set and abstract method bodies is only necessary in Java" On smalltalk instance variables are private, so if you want get/set it's value you need a getter/setter. You can argument that this is bad oo design, but it's not java exclusive.
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".