nonetheless.
For a long time -- decades -- I stuck with Emacs and minimized my use
of GUI IDE's in development. I've been a user of the Emacs command set
long before the creation of Gnu Emacs, back before ITS Emacs even (as
Emacs built on what we had before); those gestures are deeply wired
into my fingers over a period of 35 years or so. There simply wasn't
enough benefit to justify the switch.
However, I think that time has long passed. Eclipse does a lot to
enhance your development process AND your learning, and I think you
are hamstringing yourself by sticking with command-line tools. Things
like, when you type a '.' and start typing a method name. This greatly
aids the learning process, reduces typing, and best of all, it
eliminates most typos in method or field names, without having to go
through a compilation cycle.
Things like being able to on a method, field, or variable and see its
definition or implementation. Or just wave your mouse over some code
being debugged and seeing the current values of the variables.
But that's just the beginning. Eclipse has a wide range of code
refactorings built in, that allow you to do things like renames and
code rearrangement in a way that takes into account the actual
language. It will automatically make sometimes hundreds of changes,
all at once, correctly or almost correctly (requiring a bit of trivial
manual fixup, flaggged by the compiler so they're easy to find). Doing
the same thing manually the old way would often take days, and even
sometimes result in numerous bugs.
The effort to learn Eclipse really is worth the effort, and I seldom
edit code in Emacs anymore.
And I think your decision is, in the long run, impeding, rather than
aiding, your learning the platform in depth. Time is your most
precious resource. The extra visibility and efficiency that Eclipse
gives you will allow you to greatly expand your investigation and
exploration, once you're past that first barrier.
The one exception I make is production builds. IDEs simply do not give
you enough control over or visibility over the process, and do not
integrate with build automation -- and I argue that production builds
must always be automated. Unfortunately, that means a bit of
duplicated effort, but it's not hard to replicate the build process in
ant. The Android tools even automate this step, though I only use them
as a guide for various reasons.
So bottom line -- I think the only reason at this point you are
sticking with non-GUI development is because you haven't yet learned
enough about the GUIs to see the benefit to be gained. There's no
question there's a fair amount to learn -- your example of not
understanding the build errors you got is an example.
However, the ideal thing is to not figure everything out on your own,
but have someone help you get started, and get you past the steepest
part of the learning curve, at the start.
I don't think you'll find large groups of users who hate Eclipse and
would rather use command-line tools. 5 years ago, that might have been
the case. You'll find people who hate Eclipse but use it anyway
because it's better than the alternative, or who hate Eclipse and use
a competing tool, but command-line development is pretty much gone.
I will note that the Eclipse support for most other languages is
nowhere near as good as for Java. The C++ support, for example, while
usable, and something I'd have killed for 20 years ago, can't compare
to Visual C++.
BTW, I know of no modern debugger where you can insert a call to a
breakpoint. The need to edit and rebuilt has largely been eliminated
uniformly; in any event, it's not supported by Java. However, you can
create something that works almost like that -- just write a class
Debug with a method:
public void debug(String msg) { System.out("DEBUG: " + msg);
Math.mod(1, 1); // or some other trivial method call
}
Set a breakpoint on the Math.mod() call, insert the code, and run.
When you hit the breakpoint, just hit the Return from Function button
(yes, that's a difference), and you're at the point of the call. But
darned if I can see an advantage to having to edit the code to set a
breakpoint, and then edit it again to remove it!
On Dec 15, 2:07 pm, Tobiah <t...@tobiah.org> wrote:
> On 12/15/2010 12:40 PM, Frank Weiss wrote:
>
> > Well, our perception of Eclipse is 180 degrees from mine. I'm curious, what did you meant by "beast"?
>
> I guess it just seems really complex. I've never used and IDE, so there is a lot to learn.
> I did the android HelloWorld and Notepad in Eclipse and just decided to go back to the command
> line. I still push a button to compile install and run the app - it's just that the button
> is a scriipt. I'm comfortable on the command line, and I don't like to use the mouse. I also
> couldn't live without vim. I understand that there are plugins for that, but I googled around
> and gave up.
>
> Step debugging is the last thing that I need. Otherwise, I'm super happy with the SDK from
> the command line. I don't have Ctrl-Shift+O, but I'm new to Java, and new to android, so I
> don't mind that I'm forced to get familiar with the object heirarchy. I'm sure that the docs
> are more readily available from Eclipse, but the online android reference rocks.
>
> > In the OP you asked about setting breakpoints right in the code. In Eclipse debugger (and just about every GUI debugger, including
> > Firebug) you just double click in the left margin of the source code line to set a breakpoint, which is indicated by a small dot in
> > the left margin.
>
> By "in the code" I mean that I want to be able to edit my source code with an editor
> and have that generate the breakpoint. With some other debuggers, there is a function
> call that can make this happen.
>
> > When the breakpoint fires, Eclipse highlights that line. From there you can inspect variables, the stack, etc. and
> > step through the code. I've debugged with the command line before, but once I started debugging with Eclipse, Visual Studio, and
> > Firebug, I would think that having to use a command line debugger is painful.
>
> I get that it must be more streamlined, and I wanted to try it. I thought that I could just
> go to Eclipse for debugging and do everything else the same way I've been doing. I created
> a new android project from existing source, and pointed to my source tree. There were many
> errors listed, even though my app compiles and runs fine. I couldn't make sense of them.
> I tried to run the project and I got an error. I just gave up. I guess that made me think
> of the program as a beast. I will give it a try some other time. I can't make a valid choice
> until I have reached some level of familiarity with what Eclipse can do. I notice that there
> are two well represented camps on the net: those that love Eclipse and those that hate it.
> There's very little in between. I shy from GUI's in general. I always find myself doing
> repetitive mouse movements to get the same things done over and over. On the command line,
> anything repetitive is scripted. I guess I tried to further justify my original choice by
> thinking that I'd learn Java and the SDK in greater depth this way, and I might say that I
> believe that I was correct in that respect.
>
> Thanks,
>
> Toby
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
No comments:
Post a Comment