I understand your point of view -- but I'm going to argue with it 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+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en