5 ms·

Well, Eclipse's project manager is great for Java. For C I'd much rather use just a straight text editor - IDEs just get in the way. C + emacs/vi is much faste

by javanix 17y ago

Well, Eclipse's project manager is great for Java. For C I'd much rather use just a straight text editor - IDEs just get in the way. C + emacs/vi is much faster than C + Eclipse, but C is always going to be faster to write than Java just because Java has so many more layers of abstraction that require so many more lines of code.

DougBTX 17y ago
I don't understand this one, shouldn't the higher level abstractions require less code, rather then more? If not, why use the abstraction?
- nostrademons 17y ago
  It's the difference between optimizing for lines of code written vs. lines of code maintained. Many Java patterns exist so that when you need to make a change, you can change it in one place and have it propagate to every place you've used that abstraction. This often means more lines of code in total, because you effectively have to put hooks into every place you're likely to change. Whether or not this is a good tradeoff depends on two things: 1.) How much work will be spent in maintenance vs. how much will be spent writing the original program. 2.) How good your guesses are as to how the program will end up changing. It does no good to add lots of hooks and abstractions if those hooks are in the wrong places. Most of the "Java sucks" vs. "Java is the only sane language" battle comes from people not understanding that their answers to the above two questions are not likely to be the same as someone else's answers to the above two questions. For startups, it's basically a given that your guesses on how the software will change are wrong, and therefore the layers of abstraction that common Java style encourages are just wasted. Java really does suck for startups, unless you're using a platform where it's the only option (eg. mobile or IDE plugins). But for large in-house IT departments, the vast majority of work is maintenance, and it's Somebody Else's Problem if the software doesn't quite fit requirements exactly. Java makes a lot of sense in these environments.
  - Zak 17y ago
    It's the difference between optimizing for lines of code written vs. lines of code maintained. It seems odd to me to read that. From what I've seen of it, Java seems to be hard to maintain. The capacity for abstraction is limited, leading to repeated or generated code in multiple locations. To make matters worse, hooking in to things requires that they be designed to be hooked in to. Contrast Common Lisp method combination.

by javanix 17y ago

DougBTX 17y ago

I don't understand this one, shouldn't the higher level abstractions require less code, rather then more? If not, why use the abstraction?

nostrademons 17y ago
It's the difference between optimizing for lines of code written vs. lines of code maintained. Many Java patterns exist so that when you need to make a change, you can change it in one place and have it propagate to every place you've used that abstraction. This often means more lines of code in total, because you effectively have to put hooks into every place you're likely to change. Whether or not this is a good tradeoff depends on two things: 1.) How much work will be spent in maintenance vs. how much will be spent writing the original program. 2.) How good your guesses are as to how the program will end up changing. It does no good to add lots of hooks and abstractions if those hooks are in the wrong places. Most of the "Java sucks" vs. "Java is the only sane language" battle comes from people not understanding that their answers to the above two questions are not likely to be the same as someone else's answers to the above two questions. For startups, it's basically a given that your guesses on how the software will change are wrong, and therefore the layers of abstraction that common Java style encourages are just wasted. Java really does suck for startups, unless you're using a platform where it's the only option (eg. mobile or IDE plugins). But for large in-house IT departments, the vast majority of work is maintenance, and it's Somebody Else's Problem if the software doesn't quite fit requirements exactly. Java makes a lot of sense in these environments.
- Zak 17y ago
  It's the difference between optimizing for lines of code written vs. lines of code maintained. It seems odd to me to read that. From what I've seen of it, Java seems to be hard to maintain. The capacity for abstraction is limited, leading to repeated or generated code in multiple locations. To make matters worse, hooking in to things requires that they be designed to be hooked in to. Contrast Common Lisp method combination.