NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Re: A short talk with a Java developer (Score:1)
Sounds amusingly familiar (Score:1)
Yup. At $work I've joined a Java project a few months back, and that total reliance on Eclipse to take care of all the under-the-hood details (and the ensuing side-effect that no-one really know how to tinker an ant file, or compile from the command-line) is something that bemuse me to no end.
But then, this could also be a defense mechanism. When I finally found a way for eclipse to show me the classpath used for the project, I must say that a little part of me died. Ye gods was it ever prolix...
Tools that work (Score:1)
Actually, this sounds like a success to me! A high-level tool that is so successful that you don't need to read the specs for the low-level tool? That's a successful abstraction.
Re: (Score:1)
You have a different definition of "success" that I do.
Re: (Score:1)
By success, in this case I meant that someone did not need to learn something that was not relevant to getting his/her work done. Of what benefit is knowing the classpath syntax for command-line Java? Analogy: using Perl makes knowing the order of arguments of the malloc function useless. Automatic memory management is a success for Perl, like automatic project management is a success for Eclipse.
For reference, that classpath syntax is actually simple, but platform-specific (colon or semi-colon as path s
Re: (Score:1)
Ah...at that level sure. But you are taking it to the tool level which is where your Perl analogy falls apart. eclipse is not Java and "I" would think a Java programmer would know the classpath syntax.
Re: (Score:1)
You only see the difference because the Perl project-management tools aren't good enough yet.
We'll be fixing that.