5 ms·

Heck, I've never managed to get Eclipse to pull in and index even my 500,000-line code base, and I've spent weeks trying. It just falls over, paralyzed. It lite

Heck, I've never managed to get Eclipse to pull in and index even my 500,000-line code base, and I've spent weeks trying. It just falls over, paralyzed. It literally hangs forever He probably just needs to disable automatic builds. There are other automatic features that can be disabled as well. Eclipse can be stripped down like anything else. nothing that would permit the removal of the copy-and-paste duplication patterns that Java programmers think of as "inevitable boilerplate", but which are in fact easily factored out in dynamic languages. You know, I've never heard the phrase "inevitable boilerplate" from a Java programmer, though his quotation marks suggest that he has. There are some things that can really be shrunk down in non-Java languages, but a lot of the examples that people point out are harmless: System.out.println("output here"); or for (Object obj : list) { } These sorts of things don't really add to complexity. Too bad he didn't provide any specific examples of his own. Typically, when attacking Java (the most common sport in the software world today) people will pretend it has disabilities it doesn't have. like non-broken closures, that the Java community is resisting tooth and nail Another phenomenon I haven't seen too much of, I guess. Most resistence probably comes from people who know what will happen, rather than people who dislike the feature in and of itself... I'll say this about Java, since I get the impression that a lot of ynews people are in college or just out of college: I've had gigantic mountains of Java code thrown at me that I could make useful modifications to in minutes. It is hard to obfuscate. By contrast, I have dealt with Javascript codebases that were a nightmare to work with simply because the previous guy thought it useful to graft functions onto objects (or is it "prototypes") at runtime. Nice feature, if you're not inheriting it...

michaelneale 19y ago
I work on about 400K lines every other day in eclipse, no issues. Of course things are broken down into modules, maybe that helps a bit. I don't like eclipse at all, but I don't understand their complaints. Maybe back in 2003 that was a problem.
fauigerzigerk 19y ago
I've heard Java people defend boilerplate code countless times. Just take getters and setters. People will tell you "the IDE generates them anyway". What you can't do within the bounds of the language is to loop over all accessors and replace them with something else that might call the original versions. A technique that's used frequently in Rails for instance. To do that in Java you need code generators (probably built into IDEs), frameworks that supplant the entire object creation mechanism to hook in proxies, or byte code manipulation. All of these techniques are orders of magnitude more complex and error prone than dynamic metaprogramming or lisp macros. And despite all the complexity some things just can't be done. There is no way to call a Java method (using regular method call syntax) that the compiler doesn't see. So even if you know the method will be there because some other code will have created it by the time it is invoked, you still need to put a useless method stub somewhere in the source code.
qaexl 19y ago
I have not worked with Java much. I have, however, worked with Pascal, C, Objective-C, Perl, PHP, and Ruby. When the Google Android SDK came out, I downloaded Eclipse and its plugin and worked through the tutorials. Having been working with Ruby on Rails for nearly the past two years, it was a shocker at the amount of crap and copy-and-paste I had to do to get it working. And that's with the tutorial crowing about how the SDK has tools to help you save time. For example, in the SDK, you define resources in an XML file. The IDE/Android plugin will automatically build a Java file for you out of the XML file. This lets you reference the the code in there. And sure, the shift-ctrl-O to organize the library import is nice ... it is just that I never had to do that with Rails. And adding event callbacks via anonymous classes? It is incredibly awkward. In my brief excursion into Java, I think the zinger, "Typically, when attacking Java (the most common sport in the software world today) people will pretend it has disabilities it doesn't have." is grossly misinformed. The examples of System.out.println("output here"); or the for loop example is trivial compared to the power of Ruby's eigenclasses and runtime code rewriting capabilities. While working my way through that tutorial, I kept thinking to myself, "I really should not have to deal with this crap." When I was a teenager, I spent too much time coding with LPC, using the MudOS platform. This was before the Ultima Online dev team started soliciting ideas from rec.games.muds. LPC uses a C-like language, had dynamic array and hash syntaxes ported from Perl 3. You could use anonymous functions (though you could not serialize it), and reflection is built into the language. The pseudo-natural-language parser in MudOS was built to take advantage of the LPC's reflection capabilities. Being older now, I went back through some of the LPC libraries on a whim. I remembered those good old days with a sort of fuzzy, nostalgic glow. At least until I looked at the code. Looking at it now, I know with something as capable as Ruby, the code would not have had to twist itself in such awkward ways, lots of copy-and-pasting. (And just so you know, copy-and-paste on MudOS systems meant using the built in command-line 'ed' editor). "By contrast, I have dealt with Javascript codebases that were a nightmare to work with simply because the previous guy thought it useful to graft functions onto objects (or is it "prototypes") at runtime. Nice feature, if you're not inheriting it..." This actually tells me quite a bit why you like Java instead of Javascript. I didn't really feel Javascript was a compelling language until I saw the prototyping feature. The point is not to inherit it so much as to mixin code. It is a very different way of thinking. To me, overly-designed class heirarchies are as ugly and awkward to me as the prototype/code mixin is to you. In the example of writing that game, having code mixin gives you an incredible advantage. You can create game objects by mixing in different game properties. is_immune_to_poison. is_resistant_to_fire. reflects_magic :only => :fire. You don't need to set a bitfield or try to do multi-inheritance. And you would be able to define game content using the prototyping language (Javascript, Ruby, whatever) rather than writing a (breakable) parser to load up the game object definitions.

michaelneale 19y ago

I work on about 400K lines every other day in eclipse, no issues. Of course things are broken down into modules, maybe that helps a bit. I don't like eclipse at all, but I don't understand their complaints. Maybe back in 2003 that was a problem.

fauigerzigerk 19y ago

I've heard Java people defend boilerplate code countless times. Just take getters and setters. People will tell you "the IDE generates them anyway". What you can't do within the bounds of the language is to loop over all accessors and replace them with something else that might call the original versions. A technique that's used frequently in Rails for instance. To do that in Java you need code generators (probably built into IDEs), frameworks that supplant the entire object creation mechanism to hook in proxies, or byte code manipulation. All of these techniques are orders of magnitude more complex and error prone than dynamic metaprogramming or lisp macros. And despite all the complexity some things just can't be done. There is no way to call a Java method (using regular method call syntax) that the compiler doesn't see. So even if you know the method will be there because some other code will have created it by the time it is invoked, you still need to put a useless method stub somewhere in the source code.

qaexl 19y ago

I have not worked with Java much. I have, however, worked with Pascal, C, Objective-C, Perl, PHP, and Ruby. When the Google Android SDK came out, I downloaded Eclipse and its plugin and worked through the tutorials. Having been working with Ruby on Rails for nearly the past two years, it was a shocker at the amount of crap and copy-and-paste I had to do to get it working. And that's with the tutorial crowing about how the SDK has tools to help you save time. For example, in the SDK, you define resources in an XML file. The IDE/Android plugin will automatically build a Java file for you out of the XML file. This lets you reference the the code in there. And sure, the shift-ctrl-O to organize the library import is nice ... it is just that I never had to do that with Rails. And adding event callbacks via anonymous classes? It is incredibly awkward. In my brief excursion into Java, I think the zinger, "Typically, when attacking Java (the most common sport in the software world today) people will pretend it has disabilities it doesn't have." is grossly misinformed. The examples of System.out.println("output here"); or the for loop example is trivial compared to the power of Ruby's eigenclasses and runtime code rewriting capabilities. While working my way through that tutorial, I kept thinking to myself, "I really should not have to deal with this crap." When I was a teenager, I spent too much time coding with LPC, using the MudOS platform. This was before the Ultima Online dev team started soliciting ideas from rec.games.muds. LPC uses a C-like language, had dynamic array and hash syntaxes ported from Perl 3. You could use anonymous functions (though you could not serialize it), and reflection is built into the language. The pseudo-natural-language parser in MudOS was built to take advantage of the LPC's reflection capabilities. Being older now, I went back through some of the LPC libraries on a whim. I remembered those good old days with a sort of fuzzy, nostalgic glow. At least until I looked at the code. Looking at it now, I know with something as capable as Ruby, the code would not have had to twist itself in such awkward ways, lots of copy-and-pasting. (And just so you know, copy-and-paste on MudOS systems meant using the built in command-line 'ed' editor). "By contrast, I have dealt with Javascript codebases that were a nightmare to work with simply because the previous guy thought it useful to graft functions onto objects (or is it "prototypes") at runtime. Nice feature, if you're not inheriting it..." This actually tells me quite a bit why you like Java instead of Javascript. I didn't really feel Javascript was a compelling language until I saw the prototyping feature. The point is not to inherit it so much as to mixin code. It is a very different way of thinking. To me, overly-designed class heirarchies are as ugly and awkward to me as the prototype/code mixin is to you. In the example of writing that game, having code mixin gives you an incredible advantage. You can create game objects by mixing in different game properties. is_immune_to_poison. is_resistant_to_fire. reflects_magic :only => :fire. You don't need to set a bitfield or try to do multi-inheritance. And you would be able to define game content using the prototyping language (Javascript, Ruby, whatever) rather than writing a (breakable) parser to load up the game object definitions.