 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / First Aid / May 2004Question for Java Gurus
I have been a professional programmer for about 14 years on MVS, HP-UX, and Windows. I have been following Java since about 1997, but I have never done any app development in it. Here are my questions: 1. Where do the gurus go to get programming information? A newsgroup, website, what? 2. What is the best freeware IDE, and what is the best professional IDE? 3. If you were a professional programmer like me who wanted to get up to speed quickly, what resources would you use? Thank you very much for your time. > I have been a professional programmer for about 14 years on MVS, HP-UX, and > Windows. I have been following Java since about 1997, but I have never done > any app development in it. Here are my questions: > > 1. Where do the gurus go to get programming information? A newsgroup, > website, what? http://java.sun.com/ For example: http://java.sun.com/j2se/1.4.2/docs/api/ And Google Groups. > 2. What is the best freeware IDE, and what is the best professional IDE? Much debated questions. Do a Google search. As far as free ones, I use NetBeans because it's what I learned to use. It has its good points and bad points. Oracle JDeveloper looks promising, though I've only tinkered with it so far. Eclipse and IntelliJ Idea are two other free IDEs I've seen in use. However, just about any experienced Java programmer will tell you to learn the basic command-line stuff before getting into an IDE or you'll end up in trouble. The Java Tutorial (below) is good for teaching you that. > 3. If you were a professional programmer like me who wanted to get up to > speed quickly, what resources would you use? http://java.sun.com/docs/books/tutorial/index.html And Google Groups. (Notice a trend here? :-) > Thank you very much for your time. Not a problem. Good luck. <snip> >> 2. What is the best freeware IDE, and what is the best professional IDE? >> [quoted text clipped - 5 lines] >the basic command-line stuff before getting into an IDE or you'll end up in >trouble. The Java Tutorial (below) is good for teaching you that. While IntelliJ is an excellent tool (I use it), it is most definitely not free. Eclipse, however is. Pete > <snip> > [quoted text clipped - 10 lines] > While IntelliJ is an excellent tool (I use it), it is most definitely > not free. Eclipse, however is. Oops, sorry about that. Brain fart. > > I have been a professional programmer for about 14 years on MVS, HP-UX, > and [quoted text clipped - 6 lines] > > > http://java.sun.com/ plus: http://forum.java.sun.com/ http://www.javaworld.com/ http://mindprod.com/jgloss/jgloss.html I'd recommend these books: Things that you can easily get wrong in the beginning: Java Pitfalls http://www.amazon.com/exec/obidos/tg/detail/-/0471361747 There's even a new version which I don't know: More Java Pitfalls http://www.amazon.com/exec/obidos/tg/detail/-/0471237515 If you want to dig into multithreading: Concurrent Programming in Java http://www.amazon.com/exec/obidos/tg/detail/-/0201310090 Doug Lea also has a nice website at http://gee.cs.oswego.edu/dl/ Regards robert Good question and only someone whose been then there can save you time on it. While you'll inevitably end up using Borland's tools in one form or another, there are other promising platforms out there (fortunately). But Borlands freebie is not a whole lot different from their full blown version. (And ofcourse there is always the wonderful Together product which you'll find indepensible) But before you get to enjoy any of that, you really need to start at ground zero. It is quite simply, the quickest way to understand everything Java is about. To fully appreciate Java, one must try to imagine that perfect language they may have always ever thought of writing if ever they wanted to write one themselves or had the time to do so. Well, enough plugging on Java and more about what you, the seasoned programmer, must do, in order to quickly ramp up how to properly use the language. The first thing you must do is plan to spend the next 15 days going thru it's certification study guide. There are a few on the market claiming to be the #1 book for this purpose but pick only the one written by the same people that wrote the certification exam. http://www.amazon.com/exec/obidos/ASIN/0782140777/ref=pd_sxp_elt_l1/103-8442938- 6823845 that is if passing the Java Certification exam is of any interest to you. the reason why i recommend this is due to the fact that i studied this one after i used another and i can say that due to subtle differences in the texts, certain aspects of the Java language are not highlighted. i believe these subtle differences to be of the upmost importance for you, the seasoned professional, to be able to literally port over your experiences with other developement languages and understand how things are done in Java. now, i know, you'll probably be thinking "but i can do this in a day". why rush? what's the rush? why don't you plan instead to go get this book and find a nice coffee shop somewhere and go thru each chapter, one by one over the course of a week or two absorbing each concept as they come to you (and try not to cheat, because you'll only be cheating on yourself - the answers at the end of each chapter will be an excellent way for you to figure out what you don't fully understand). beyond that, your in for bit of a surprise. you are probably also thinking, well, it looks nice enough (Java), but i'm not sure if it's a real heavy duty language like C++. well if that's you line of thinking, i'll bet the stockmarket your in for a rather delightful surprise.... but just like the matrix, i can only offer you the red pill, you have to see it for yourself... as for the seemingly more advanced tools like J2EE, get an understanding of RMI, JDBC and perhaps JNI first. right now, there seems to be a Java framework for every major concept out there and many to choose from to suit your purposes. what i like about it the most though i think is that everything just seems to want to work together, no struggle. everything just seems to fit so nicely. i don't know why C++ people are so intimidated by it, they shouldn't be. use C++ for developing operating systems and areas where tight memory management is absolutely required, use Java where garabage collection is not top priority or wherever you want the best of both worlds and need to get something out the door without reinventing the wheel (for the record, JIT native Java code runs 99.99% as fast as C++, sometimes faster depending on the app). there are other languages too, do not discount those. just don't fall into the trap of Java for everything but appreciate it for what it is.... but being a "professional programmer" i don't think i have to tell you that... cheers - perry > I have been a professional programmer for about 14 years on MVS, HP-UX, and > Windows. I have been following Java since about 1997, but I have never done [quoted text clipped - 9 lines] > > Thank you very much for your time. > 1. Where do the gurus go to get programming information? A newsgroup, > website, what? The documentation (the javadoc that comes with the JDK). The source (comes in a zip file with the JDK) These newsgroups. Worth whisking through the Java tutorial on Sun's java site. Other than that it depends on your tastes and on how you learn. Some people love books with lots of examples, others (like me) prefer to work as much as possible from the raw specs and standards. One thing you should decide early is whether you are attempting to learn the Java language (and the associated standard library), or whether you are focussing on learning some application domain like J2EE. Personally I'd advise against trying to learn domain specific stuff (even you have considerable experience already of that domain) until you've got the foundations solid. Another thing to ponder: are you already an experienced OO programmer ? That's a very difficult question to answer, even for yourself, since there are a lot more programmers who /think/ they understand and use OO properly, than there are who actually do. > 2. What is the best freeware IDE, and what is the best professional IDE? I think most people will tell you the same thing. Don't use an IDE until *after* you've got well underway with Java. One reason is that IDEs by there very nature attempt to hide some of the complexity of "what's really going on", and you don't need that when you are trying to /learn/ what's really going on. Another reason, paradoxically, is that all the IDEs I've tried are massively complicated and so you end up putting more effort into learning the IDE than into anything constructive (and, too, you have to understand Java concepts pretty well before you can understand what the IDEs are trying to do). The only reservation I have about that advice is that if you are new to OO, then using an environment that is designed to emphasise OBJECTS may be an enormous help. If that's the case then the /best/ thing you can do is go learn Smalltalk before Java, but assuming that's not an option for you ;-) then maybe using the BlueJ environment would be a good idea. I haven't tried it myself, but I have read some of their discussion of what they are trying to do and it looks good. (None of the major IDEs emphasise objects in this way. They are wretched from that point of view -- all you ever see is the source code for classes, you never get a feel for working with real objects at all.) > 3. If you were a professional programmer like me who wanted to get up to > speed quickly, what resources would you use? Read as much as you can stand of the Java tutorial. Find a book which approaches the subject in a way you are happy with (many people find Bruce Eckel's "Thinking in Java" to their taste). Then *practise*... Good luck -- chris And as for where to get programming information on Java, true, java.sun.com is the authority but they are not always the best tutors. however, i have another surprise for you, depending on your budget, plan on picking up a new Java book per week. the addiction hit me so bad, i lined my office wall off with primarily Java books. as a matter of fact for badness, i'll go find what i did with my old picture and post it for you. they are expensive but you can save money in two ways. one, to write all this off as a business expense in one form or another. the 2nd method is to go to 2nd hand book stores, because the beauty of Java is that it really hasn't changed all that much since it's inception, hence books written from the start are actually very useful. just another reflection of how everything works well and builds on top of itself with Java. i can say, it's been the best attempt at the principles of OO i've ever seen successfully used in today's programming environment. as for websites there's a new one everyday.... other than that you'll have to contact a consultant from one of the more reputable companies, that is, with a focus on doing quality work versus wasting your time... the best one i worked for is based in Dallas, TX. www.osgcorp.com and get whoever your working for to hire some consultants to come in and give you a first hand view on Java and Object design principles and how it can best help your company. cheers - perry > I have been a professional programmer for about 14 years on MVS, HP-UX, and > Windows. I have been following Java since about 1997, but I have never done [quoted text clipped - 9 lines] > > Thank you very much for your time. >2. What is the best freeware IDE, and what is the best professional IDE? I'm no Guru but I have spent some time looking at IDE's. I was coming from Visual Basic and my requirements were minimum cost and a "What You See Is What You Get" editor for graphical user interfaces. Here are my findings. Netbeans (www.netbeans.org) is free and Open Source. I think you will find it the best choice. Borland's JBuilder Foundation (http://www.borland.com/jbuilder/foundation/) is also a free download. I found JBuilder felt the closest to the VB IDE. Oracle's JDeveloper (http://otn.oracle.com/products/jdev/content.html) is a free download but the license severely restricts what you can do with programs you write if you do not pay for it. If you are into large database applications it is well worth your attention because it comes with the equivalent of VB's data bound controls and is the cheapest of the commercial "Enterprise" IDEs. It's also a great WYSIWIG HTML editor. Sun One Studio 4 Community Edition, which is derived from Netbeans, is still available, without charge, from http://jsecom16d.sun.com/ECom/EComActionServlet?StoreId=8&PartDetailId=FJCI9-401 -TL9M&TransactionId=try&LMLoadBalanced= but has been superseded by Studio 5. Sun suggest you use Netbeans if you want a free version. Sun have some free on-line courses in using Sun One and the transition from Sun One to NetBeans is trivial. Websphere Studio Application Developer (http://www-3.ibm.com/software/awdtools/studioappdev/) is based on Eclipse but has many enhancements including a WYSIWYG editor for GUI's. It is not free but a 60 day trial is available. I mention Eclipse in this summary only because there will be an irate follow up if I don't. :) Eclipse (www.eclipse.org) is a popular Open Source IDE and there are free or cheap plug-ins like http://www.cloudgarden.com/jigloo/index.html, http://www.assisiplugins.com/index_start.html and http://www.eclipse.org/vep/ that provide WYSIWYG GUI development. To complete this list I should also mention the popular IntelliJ IDEA (http://www.jetbrains.com/idea/index.html) which has recently added a GUI builder. It is not free but you can download a 30 day trial. I have not tried it. In comp.lang.java.advocacy David Segall <david@nowhere.net> wrote or quoted: > Netbeans (www.netbeans.org) is free and Open Source. I think you will > find it the best choice. [...] > I mention Eclipse in this summary only because there will be an irate > follow up if I don't. :) Giving it that sort of billing is likely to prove ineffective at preventing such responses.  Signature__________ |im |yler http://timtyler.org/ tim@tt1lock.org Remove lock to reply. > I have been a professional programmer for about 14 years on MVS, HP-UX, and > Windows. I have been following Java since about 1997, but I have never done > any app development in it. Here are my questions: > > 1. Where do the gurus go to get programming information? A newsgroup, > website, what? Multiple resources, really. I read textbooks, visit ngs. Some people like mags, but I feel they re-hash a lot of information that is free elsewhere. > 2. What is the best freeware IDE, and what is the best professional IDE? I, personally, use a plain text editor. The IDEs will generate lots of code for you, but that doesn't help you learn what the code does. > 3. If you were a professional programmer like me who wanted to get up to > speed quickly, what resources would you use? The platform is huge. Read java.sun.com to get a sense of the breadth of technologies out there. White papers or other "executive summaries" will provide similar perspective. But to know the language you have to write the code. If you know what specific applications you are targeting, focus on related technologies. As you write the code, you will find yourself reading the API documentation. That's where the learning really happens, IMO. Apache.org is one big resource for learning about how the technology is advancing. Folks keeping building more software on top of existing software. Finally, learn the command-line tools before you get wrapped up on what IDE(s) to pick. All of those IDEs are using the command-line tools. You can probably get as many different opinions on how to go about this as there are respondents. enrique@pineda.org (Enrique) wrote in message news: > > 2. What is the best freeware IDE, and what is the best professional IDE? > > I, personally, use a plain text editor. The IDEs will generate lots > of code for you, but that doesn't help you learn what the code does. I think this is very bad advice. I know, it is repeatedly said that IDEs are bad for learning Java, because they - generate too much code for you, or - are too complicated, or - hide too much stuff from you - or all of the above. While this is true for many IDEs, it is not true for all of them. I am involved with the development of an educational IDE (so I am heavily biased!), and I am convinced that you can learn to understand OO _much_ better given the right environment tools. The solution is not avoiding IDEs, it is choosing the right IDE. This question comes up every couple of weeks, so a while ago I wrote a summary of arguments why I think the "Don't Use An IDE"- advice is wrong. If you're interested, you can find it here: http://homepage.mac.com/mkolling/mrt/C54415237/E848832883/index.html Regards, Michael > enrique@pineda.org (Enrique) wrote in message news: > [quoted text clipped - 32 lines] > > Michael I can agree with you on all but your third point. I would like to say a majority, but I'll limit it to "a whole lot" of the newbs that come through the groups (not mailing lists, btw) are having problems related to either classpath or directory structure. If everyone took the time to at least write their "Hello World" program in a text editor and compile and run it at the command line, I suspect we'd all be better off. > I can agree with you on all but your third point. I would like to say a > majority, but I'll limit it to "a whole lot" of the newbs that come through > the groups (not mailing lists, btw) are having problems related to either > classpath or directory structure. If everyone took the time to at least > write their "Hello World" program in a text editor and compile and run it at > the command line, I suspect we'd all be better off. I must be missing something here. It seems to me that, if students are constantly running into problems with the details of command-line Java tools (such as classpath and the like), then it would be best if they didn't use those command-line Java tools. You seem to conclude the opposite; that they should face them head-on and overcome their difficulties. I suspect that the difference lies in how fundamental we think those concepts are. I think that the classpath environment variable is a rather peculiar aspect of the JDK command-line tools. I much prefer, say, Eclipse 3.0, where I can choose project properties and just check all of the user-defined libraries that my project uses and expect everything to work, without dealing with questions of whether I can set an environment variable in one place or another, or oops I only set it in this shell so it doesn't appear in other shells, etc. I think it's clearly possible to develop Java software without worrying one bit about environment variables. So I question why understanding the CLASSPATH environment variable (or command-line option, etc) would be a necessary prerequisite to learning programming in Java. So, I guess I'm with Michael on this one. Signaturewww.designacourse.com The Easiest Way to Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation > I suspect that the difference lies in how fundamental we think > those concepts are. I think that the classpath environment [quoted text clipped - 10 lines] > command-line option, etc) would be a necessary prerequisite to > learning programming in Java. This is analogous to java programmers thinking they can code database applications without understanding the underlying database. Oh, I'm sorry, the JVM is the only world one needs to know. SignatureGalen Boyer > > I suspect that the difference lies in how fundamental we think > > those concepts are. [...] > This is analogous to java programmers thinking they can code > database applications without understanding the underlying > database. Oh, I'm sorry, the JVM is the only world one needs to > know. Well, I'm sure you won't be surprised to find that I disagree. What we're talking about in this case are two different ways to provide the same information to the JVM. One is rather more convenient because it makes use of both persistent knowledge about the subject matter (which JAR files and classes correspond to which libraries) and GUI interfaces (adding things to a list rather than redefining an environment variable). The other works, but is rather arcane. And we're talking about an educational environment: which things should be taught. The motivations for teaching a concept are (a) how relevant it is to the teaching goal, and (b) how necessary it is for the student to make progress. Clearly, setting the CLASSPATH environment variable is neither the point of teaching programming, nor necessary to succeed in Java programming, assuming you have the right tools. The choice of setting PATH and CLASSPATH versus using an integrated environment is relevant to neither functionality nor any other characteristic of the result of programming. That's clearly different from a database, where the information model of the database, its performance characteristics, and its features have a direct impact on the software development process. Signaturewww.designacourse.com The Easiest Way to Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation Hello, Chris Smith ! You wrote: > And we're talking about an educational environment: which things should > be taught. The motivations for teaching a concept are (a) how relevant [quoted text clipped - 5 lines] > relevant to neither functionality nor any other characteristic of the > result of programming. To go along with this train of thought is not only which things are taught, but *when* they are taught. So in addition to your decision guidelines is the question of whether the student has enough of the basics to serve as a framework for understanding the new concept. In this case understanding the classpath requires a great deal of other knowledge before tere is evenm a basis for understanding it. That is why an IDE like BlueJ that hides this from the student is so valuable. The other issue I haven't seen mentioned is a good debugger. Without an IDE the student is left with no tools for figuring out what went wrong. SignatureDale King My Blog: http://daleking.homedns.org/Blog >> > I suspect that the difference lies in how fundamental we >> > think those concepts are. [...] [quoted text clipped - 13 lines] > things to a list rather than redefining an environment > variable). The other works, but is rather arcane. No, its different, but setting an environmental variable is not an arcane operation, especially for a programmer. > And we're talking about an educational environment: which > things should be taught. How to program involves understanding the environment as well as the language. The best programming teacher I ever had was an author of a compiler. He not only taught us how to program but what was going on as the compile translated what we wrote to what it could understand. > The motivations for teaching a concept are (a) how relevant it > is to the teaching goal, and (b) how necessary it is for the > student to make progress. It isn't progress if the programmer is completely dependent on a tool or some admin guy to set up his environment for him. > Clearly, setting the CLASSPATH environment variable is neither > the point of teaching programming, nor necessary to succeed in > Java programming, assuming you have the right tools. Look at your assumption and you see your flaw. > The choice of setting PATH and CLASSPATH versus using an > integrated environment is relevant to neither functionality nor > any other characteristic of the result of programming. Understanding one's environment is expected, so it should be taught. Just because there are tools around that might make it so you don't have to perform that operation doesn't mean those operations are now, somehow, arcane and don't need to be understood. > That's clearly different from a database, where the information > model of the database, its performance characteristics, and its > features have a direct impact on the software development > process. Man, I can't believe you don't think there are performance characteristics of the JVM. SignatureGalen Boyer > [a lot of stuff] I don't find it promising to engage in this conversation, given your insulting tone and your preference to pick out ways to mock me by misconstruing my comments instead of actually reading what I said. Best of luck, Signaturewww.designacourse.com The Easiest Way to Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation > And we're talking about an educational environment: which things should > be taught. The motivations for teaching a concept are (a) how relevant [quoted text clipped - 5 lines] > relevant to neither functionality nor any other characteristic of the > result of programming. I can see your logic, but I find it unconvincing. The problem is that (in my experience with Java IDEs) getting the relevant settings right is at least as difficult as it is in a command-line environment. And that's a problem -- in a command line env, the beginning programmer is seeing the issues clearly separated out from other issues. He or she can see where the classfiles are being generated, can change directories and re-run the java command, and so on. I.e. he or she is getting a chance to learn the abstract concepts of "locating classfiles" in a way that doesn't mix in a load of other issues. In a typical IDE, in my experience, the same problems of locating stuff arise, but the "solution" is buried in ISE settings, and arcane (unless you already understand the concepts) library lists. All the would-be programmer is going to learn is how to treat a /specific/ IDE as a black box and a magical recipe to "make it work" -- not a valuable learning experience. OK, that's exaggerating slightly, but not much, and only to make the point clear. -- chris > This is analogous to java programmers thinking they can code > database applications without understanding the underlying > database. Oh, I'm sorry, the JVM is the only world one needs to > know. Man, talk about a broad stroke! "java programmers" know nothing about databases! Oh I'm sorry, *you're world* must be the only world one needs to know. >> This is analogous to java programmers thinking they can code >> database applications without understanding the underlying [quoted text clipped - 6 lines] > Oh I'm sorry, *you're world* must be the only world one needs > to know. Nope. Met quite a few java programmers that are quite good at db work. Understand what they are good at and that there are major differences between the platforms. But I've met far more that think it is a black box and they should be able to treat it that way. SignatureGalen Boyer > > I can agree with you on all but your third point. I would like to say a > > majority, but I'll limit it to "a whole lot" of the newbs that come through [quoted text clipped - 9 lines] > opposite; that they should face them head-on and overcome their > difficulties. Others have made some good replies, so I'll be short. I wasn't talking about people running into classpath issues while doing command line work. I'm talking about the multitude that have classpath issues and don't even know what the word "classpath" means because their IDE has been shielding them from it. Whatever your opinions otherwise, you must acknowledge that the Java classpath is at the very core of how Java works, that it must be set properly in one way or another for *any* Java-based application to work, and that a programmer that knows about it is better able to diagnose NoClassDefFoundErrors than one that doesn't. > you must acknowledge that the Java classpath is at the very > core of how Java works, that it must be set properly in one way > or another for *any* Java-based application to work, and that a > programmer that knows about it is better able to diagnose > NoClassDefFoundErrors than one that doesn't. But, based on what they are saying, all you need is a proper tool. If you get that error, you should just find a new IDE. But, wait a minute, isn't downloading from the web an arcane operation? SignatureGalen Boyer > Others have made some good replies, so I'll be short. That's okay. I much prefer your reply to the insulting rhetoric coming from Galen. > I wasn't talking about > people running into classpath issues while doing command line work. I'm > talking about the multitude that have classpath issues and don't even know > what the word "classpath" means because their IDE has been shielding them > from it. Okay, in which case it's clear that their environment is impeding their success at learning Java. At that point, it's necessary to either teach how to use it or choose a different tool. Of course, I'm not advocating switching tools; that has an inherent cost so that it's best to probably plow ahead and teach the student how to locate their third-party classes in whatever environment has been chosen. And I'm all for choosing an environment that's conducive to learning and understanding; and that's more likely to be the command line than it is to be Eclipse, for example. But I don't think it *has* to be the command line. BlueJ is very promising in terms of making things work without dealing with classpath issues. > Whatever your opinions otherwise, you must acknowledge that the > Java classpath is at the very core of how Java works, that it must be set > properly in one way or another for *any* Java-based application to work, and > that a programmer that knows about it is better able to diagnose > NoClassDefFoundErrors than one that doesn't. You see, I don't acknowledge that. The classpath falls into the realm of "making your tools work". In the context of teaching computer programming, that's a negligible space of education. The classpath is a fundamental concept of neither programming in general nor the Java programming language. The JVM spec, for example, suggests the classpath as one possible implementation of locating Java classes, but in no way requires its use. The only reason it seems any more sensible to call CLASSPATH a core part of Java than, for example, calling some specific method of location C's angle-bracket includes a core part of C, is that Java virtual machines happen to implement it a little more consistently. On top of that, in practice few Java developers need to deal with classpath issues in their regular line of work. Probably the vast majority of Java code is written in a servlet or EJB environment, in which there are other ways of providing references to third-party libraries (e.g., WEB-INF/lib), and use of the classpath in the invoking JVM is terribly poor form and non-portable. Applets can't reasonably use the classpath. The majority of application code, which is the major remaining bit, ought to be deployed as executable JAR images or Java WebStart applications, in which case the standard mechanisms for setting classpath are ignored entirely. IMHO, the only possible justification for teaching the classpath to programming students is that they might need to deal with it in order to see the immediate results of their work in simple test code. If they can see the results of their work otherwise without incurring other negative consequences, then why bother? Signaturewww.designacourse.com The Easiest Way to Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation > > Others have made some good replies, so I'll be short. > [quoted text clipped - 20 lines] > promising in terms of making things work without dealing with classpath > issues. I think we're seeing eye to eye here now. :-) > > Whatever your opinions otherwise, you must acknowledge that the > > Java classpath is at the very core of how Java works, that it must be set [quoted text clipped - 29 lines] > can see the results of their work otherwise without incurring other > negative consequences, then why bother? I see where you're coming from, but still can't entirely agree. Whether you're developing webapps or applets or whatever doesn't matter at all. You still have to compile into class files, and for that the compiler has to know where to go to get the details of the pertinent classes. However your IDE chooses to implement it, it's essentially the classpath. I've seen a fair bit of confusion among new programmers using NetBeans about "why class X can't see class Y". (The NetBeans classpath includes any directory or JAR that's "mounted".) > I see where you're coming from, but still can't entirely agree. Whether > you're developing webapps or applets or whatever doesn't matter at all. You [quoted text clipped - 4 lines] > X can't see class Y". (The NetBeans classpath includes any directory or JAR > that's "mounted".) Let's draw a distinction (and it's an important one, in my view) between the general concept that a compiler and application need to be told the location of their code, and the specific mechanism of doing so. Certainly students need to be taught that they have to specify the location of their code to development tools. But it's the mechanism of doing so in the command-line tools that I don't think of as a core educational goal. Clearly, that mechanism differs in practice depending on the environment and tools, as I explained before. Yes you need to specify the location of code in all cases, but in my experience more people are tripped up by the mechanism of doing that, rather than by the need to do it in the first place. Signaturewww.designacourse.com The Easiest Way to Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation > > I see where you're coming from, but still can't entirely agree. Whether > > you're developing webapps or applets or whatever doesn't matter at all. You [quoted text clipped - 18 lines] > the mechanism of doing that, rather than by the need to do it in the > first place. Still, how do IDE's compile code? They call javac, just as you would from the command line. You just don't see it happening. This is why some people (including myself) recommend doing a little compiling on your own, just so you can see what's going on behind the scenes and have a frame of reference for what the IDE is actually doing. As for the classpath setting itself, any IDE or J2EE container I've ever seen passes a classpath to javac.exe and/or java.exe. Your development and runtime environments don't matter. The classpath must always be there unless, as you said earlier, you're using some odd compiler that decides to implement it differently. But then it would just be the same thing under a different name, I think. > > Clearly, that mechanism differs in practice depending on the environment > > and tools, as I explained before. Yes you need to specify the location > > of code in all cases, but in my experience more people are tripped up by > > the mechanism of doing that, rather than by the need to do it in the > > first place. > Still, how do IDE's compile code? They call javac, just as you would from > the command line. You just don't see it happening. Sometimes that's true. On the other hand, I use Eclipse, which contains its own compiler and doesn't use javac at all. I'm not aware of any ability to use Eclipse's compiler from the command line, and I doubt there exists code to parse a "-classpath" command line option or to read the CLASSPATH environment variable from within Eclipse. So you say: > unless, as you said earlier, you're using > some odd compiler that decides to implement it differently. But then it > would just be the same thing under a different name, I think. As for whether Eclipse's compiler works in a similar way, there are perspectives from which it does, and perspectives from which it doesn't. It certainly offers the same basic choices (add a JAR file or a directory of classes) at its core, and there are *some* of the same problems that could trip people up (for example, I could see someone accidentally adding a directory to an Eclipse user library configuration and expecting all the JAR files in that library to be added), but there are others that simply don't apply (such as whether to use ; or : as a path separator, or most importantly where to set an environment variable in your specific operating system so that it's consistently available). Given that Eclipse is probably one of the most commonly used Java compilers out there, I don't think it's quite fair to characterize non- classpath implementations of compilers as a fringe case. Instead, it makes sense to admit that the mechanism of locating code is pretty much unspecified, and that some tool sets use CLASSPATH as their implementation because it's the only suggestion provided by the (non- normative section of the) specification. It then makes sense to treat the characteristic of calling javac behind the scenes as an implementation detail... one that might or might not be there, and that could be easily changed in the future without changing the expected behavior of the environment. Speaking of virtual machines, you have an initially stronger argument in that most common virtual machines use something like CLASSPATH (except that some third-party implementations lack Sun's rt.jar special case, so you have to locate the system classes and include them in the CLASSPATH- equivalent mechanism, so there are still differences). Except that this is exactly when non-application code (such as servlets, applets, midlets, etc.) and applications packaged as executable JAR files start to be an exception, so that worrying about classpath is largely limited to applications distributed as a bundle of loose class files. > This is why some people > (including myself) recommend doing a little compiling on your own, just so > you can see what's going on behind the scenes and have a frame of reference > for what the IDE is actually doing. But this is assuming that the IDE is using javac as its compiler, and/or that you're running your code as an application. I certainly don't mean to overstate my case. I don't want to encourage new developers to grab Eclipse, or any other environment that adds too much complexity to be easily used. I just think a sort of cult following has grown around the advice to avoid IDEs when learning, and it reflects unfairly on options like BlueJ, which is designed for learning and does an excellent job of it; or on simple environments like JCreator, for that matter, which is simple enough to help Java students without adding extra matters to confuse things. Simply put, although I think many IDEs get in the way of learning, I don't think that'd true even remotely because they save you from CLASSPATH hassles. CLASSPATH hassles are the opposite of good education in programming, not its goal, and any way you can find to avoid them is progress. Signaturewww.designacourse.com The Easiest Way to Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation > Still, how do IDE's compile code? They call javac, just as you would from > the command line. You just don't see it happening. This is why some people > (including myself) recommend doing a little compiling on your own, just so > you can see what's going on behind the scenes and have a frame of reference > for what the IDE is actually doing. I fail to see how typing "javac ..." compared to clicking a "Compile" button enlightens you any more about what is going on "behind the scenes". How are you doing "compiling on your own" when invoking the compiler via a text command, but not when you invoke it via a button? The difference is completely arbitrary. It is as if I argure that you only do it properly when you type in the raw ASCII codes for the invocation... The question here seems to be the exact line people draw between accepted abstraction and "magic that keeps you dumb". The problem is that the real criteria people use to draw this line usually is: the way I have learned it myself is the only real way to do it. I have talked to many people who argued that students need to learn assembly language first to properly understand what they are doing (of course these are usually the people who themsleves started with assembly language), others argue that everyone should at least know how the compiler works (those are the ones that ...), and others argue that you need to learn procedural programming before you can understand OO (those are the ones -- you get the idea). Arguing that invoking a compiler with a text based commend is better (more "doing it on your own") is in the same spirit, me thinks. Cheers, Michael > I fail to see how typing "javac ..." compared to clicking a "Compile" > button enlightens you any more about what is going on "behind the > scenes". It's not in the 'javac', it's in the '...'. ;-) Knowing how to set those parameters and the effect that they have, then enables you to configure most IDE's to do more subtle things than can otherwise be achieved by 'clicking a button'. SignatureAndrew Thompson http://www.PhySci.org/ Open-source software suite http://www.PhySci.org/codes/ Web & IT Help http://www.1point1C.org/ Science & Technology > I have talked to many people who argued that students need to learn > assembly language first to properly understand what they are doing (of [quoted text clipped - 3 lines] > that you need to learn procedural programming before you can > understand OO (those are the ones -- you get the idea). I think it would be more fair to suggest that the metric such people are using is "the lowest level you MIGHT have to drop down to". I didn't start with assembly language, for instance, so your thesis doesn't apply to me. But I *am* stymied on a project right now by my lack of assembly experience (I need to overwrite some stack pointers and haven't found the time yet to go groveling around learning the assembly stuff). That's a legitimate case where I have to drop down to a level I wouldn't normally have to. By the same token, people who argue that you should learn your way around outside the GUI are afraid that some day you'll need to do something the GUI/IDE doesn't handle for you. Or that you'll need to work around a bug in the IDE. Using Windows for analogy, I cannot count the number of times some GUI has let me down and I had to straighten out the problem by going to a command-line tool, or direct to the registry, or whatever. And since the GUI never tells you what config file or registry entry it's modifying under the surface, it's a classic case of "magic that keeps you dumb". And I've used plenty of other tools whose GUI's either (a) have bugs requiring you to bypass them at times or (b) only cover some fraction of the functionality available in the underlying engine. Bottom line, when IDE's work so reliably and cover all possible use cases, the learn-the-command-line people will fade away. But that hasn't happened yet. SignatureM.Biswas Mohun Biswas <m.biswas@invalid.addr> wrote in message news: > I think it would be more fair to suggest that the metric such people are > using is "the lowest level you MIGHT have to drop down to". ... > By the same token, people who argue that you should learn your way > around outside the GUI are afraid that some day you'll need to do > something the GUI/IDE doesn't handle for you. I have the impression you are wandering off the original topic of this discussion. I don't think (as I read this discussion) that anyone ever argued that you should not learn to use the command line, not learn compiler options, not learn the specific internals, etc. I would claim that every good programmer should definitely know how a compiler works and how to write assembly language. But that's not the point. What we were discussing (or so I thought) is how a beginner should start to begin learning Java. It is a pedagogical problem to try to teach too many things _at the same time_. When I argued to avoid unnecessary detail (such as compiler options), I was not implying that nobody should learn about those. Everybody should. But nobody should be required to have to slough their way through those details while they are trying to learn to program. Handling classpath options is a distraction while you are trying to learn what objects and classes are, and how you structure an OO program. The necessity to learn a lot of things does not mean that you have to learn everything at the same time. In computing education, there is a 'pedagogical patterns' movement (see http://www.pedagogicalpatterns.org/ and http://csis.pace.edu/~bergin/#pedpat ). These people collect and describe successful computing teaching methodology (in a pattern language), and one of their most popular patterns is 'Early Bird' (see http://csis.pace.edu/~bergin/PedPat1.3.html ). 'Early Bird' describes a pedagogical technique that is based on identifying the most important learning goals, and addressing them early and often. If you goal is to learn object-oriented programming with Java, then these goals would have to be understanding objects, classes, methods, encapsulation and abstraction. Things like classpaths, compiler options, and even GUI building are details compared to those. Sure, Chris Uppal's earlier remark that this does not apply when you are an experienced programmer who just wants to switch to Java is very true. That's a different situation. But Galen Boyer made a remark: "The only problem I see with this approach is that you've set the expectation that they won't need to know it. Alot of them will spend the rest of their programming lives staying away from the guts because their first taste was with something that "just worked". " This, I cannot see at all. I have not seen any evidence, either in the literature or in my work, that supports this one bit. I would like to know what this statement is based on. (I am working in training programmers, and have done so for many years, starting from beginners through to masters and PhD level degrees. I have certainly watched many students start with an educational environment, and I have never observed the effect that Galen states there.) And, of course, I expect people to know the detail at the end. My students have written compilers and assemblers before they leave our institution, they have experience in language design, and are experienced in the construction of OO systems. Yet they start with a learning environment that hides the Java VM details. Regards, Michael > Mohun Biswas <m.biswas@invalid.addr> wrote in message news: > But Galen Boyer made a remark: "The only problem I see with [quoted text clipped - 5 lines] > This, I cannot see at all. I have not seen any evidence, either > in the literature or in my work, that supports this one bit. I see this alot. The very big example of a GUI to command-line fight is when a windows user is asked to start using Unix, ie, learning how to be proficient with a command line dominated environment. Most of them never get past "ls", and they stay frustrated by the "arcaneness" of it. But, when a Unix user is asked to learn and use windows, she will and usually becomes quite skilled at it. This is mostly attributable to the ease of windows, but my point is that someone who started with the command-line will usually be comfortable in both worlds, but not the other way around. Another analogous example (and directly in the middle of my profession) is when an entry level Oracle developer starts out with a GUI tool and not sqlplus, he invariably never gravitates toward learning how to use sqlplus effectively. He considers it arcane and hard to use. That becomes a huge hindrance when the database has been deployed to the production environment and he is tasked with analyzing why performance is an issue. The only tool you will be given will be sqlplus. If you start out learning how to be proficient with the most basic tool, then the GUI just becomes "another tool". Maybe this is my main issue. Starting out with a "GUI first" learning approach usually means you only have one tool type in your professional toolkit. The windows only user, and this includes developers, comes to depend on the GUI tool and will have a very hard time when those tools aren't available, while the command-line user can much more easily move to a GUI world. Even to the point that if you took away his command-line and made him only use a GUI, he'd be fine. Could the same be said of the GUI only user? > I would like to know what this statement is based on. (I am > working in training programmers, and have done so for many > years, starting from beginners through to masters and PhD level > degrees. I have certainly watched many students start with an > educational environment, and I have never observed the effect > that Galen states there.) I'm not describing effects seen from a professor student relationship because I don't teach, but instead what I've seen in professional programming environments. I would bet this, that if students learn with a GUI, they don't want to and find it a chore to learn how to program without one. This is why I would suggest they first learn without one. > And, of course, I expect people to know the detail at the > end. My students have written compilers and assemblers before > they leave our institution, they have experience in language > design, and are experienced in the construction of OO systems. Well, as long as you make sure they do, then, I think you are doing the correct thing. My question is, do they gravitate toward the "I have to bring it all together myself" that you get in the command-line environment or do you see them considering it a chore? If its a chore, then you may be doing them a disservice by starting with a GUI. In the words a teacher would love, programmers should thirst for understanding everything about their environments. SignatureGalen Boyer > The question here seems to be the exact line people draw between > accepted abstraction and "magic that keeps you dumb". The problem is > that the real criteria people use to draw this line usually is: the > way I have learned it myself is the only real way to do it. </snip> Well. I'm in a bit of a quandry, here. I started my programming learning with java, using the GUI on a windows system. The next year of my university education, I was using gvim on a SunRay. Concepts-wise, that first year was mostly cut-and-paste; usually from examples that didn't compile. I learnt a lot from fixing the lecturer's mistakes. The second year was much the same, except I was producing compile-worthy code away from computers for much of the assessment, and dealing with a few environmental issues. I learnt a bit of syntax, a few data structures, UML, the theory about testing ... but didn't really understand what it was that I was doing, and realistically, this 'learning' could have been done in about a month, or perhaps six weeks, if it had been the only focus of study. In parallel with this, I was also learning about a couple microprocessors and their attendant assembly languages. This didn't teach me much about programming either, except about 'how to fit a complex program in 512 bytes' and 'which pins to solder to which holes'. In my third year, things finally started to come together: I learnt about compilers, and suddenly a few more things made sense. I learnt about functional and logical programming, and twisted my brain in new and interesting ways. I learnt about the guts of an operating system. I learnt about networking - and incidentally about how objects interact with one another in a non-trivial system. I could finally see what on earth was going on. A couple of years later, here I am, still learning. But at least now I have a solid basis from which to build. In short, I'd have to say that for a new java programmer, who is also new to programming, you're not going to be able to teach them everything overnight, or even in a short amount of time. Yes, by all means, start with the GUI, but give them buggy programs to fix, so that they learn all about errors and what they mean. Then throw them at the 'primitive' interface, like a vim or an emacs, with command-line compiling, let them struggle to understand the environment within which they operate - but after they've sorted the basic language concepts. Then move on to more complex tasks that require a lot of concept development - lots of object interaction, compilers, that sort of jazz. That's my advice, as a recent student of the system. Elspeth. [..] > I can agree with you on all but your third point. I would like to say a > majority, but I'll limit it to "a whole lot" of the newbs that come through > the groups (not mailing lists, btw) are having problems related to either > classpath or directory structure. If everyone took the time to at least > write their "Hello World" program in a text editor and compile and run it at > the command line, I suspect we'd all be better off. i'm happy with the command-line stuff i *already* know. however, i've yet to use a class path. i'm ok with vi/pico/choose your poison. in fact, i'd happily muck around in those. i'm on a mac (the one with the hemisphere base and swivel screen) at an internet cafe. having no idea how to use fetch, i spent five minutes finding the console to use ftp the old-school way. once you know how to burn a cd-rom with the command line, for example, it's easy. however, as a newbie, i still have no idea how to compile a java program. i don't want to mess around with settings, just hit compile foo.java + extraneous switches/whatever. i'm waiting for "head first java" to arrive from the library so i can take a closer look at this. learning command line stuff from scratch (say, from windowsXP) would probably confuse people. -javac@mail.com > > I, personally, use a plain text editor. The IDEs will generate lots > > of code for you, but that doesn't help you learn what the code does. > > I think this is very bad advice. No. It's very *good* advice. Maybe not the *best possible* advice, but still very good. People tend to think that all IDEs are roughly the same except for different ticks in their feature lists. Indeed for the vast bulk of Java IDEs that has been true (VAJ was something of an exception). And -- since they are also unsuitable for learning -- the general advice is to avoid them. If there was much difference between them (on this issue) then the advice would be more specific. I quite agree that it's not /necessarily/ the case that an IDE is bad for learning. In fact its demonstrably possible to make an IDE that is excellent for learning -- although Java is not the language of choice for this. I mentioned BlueJ in my own reply to the OP, as a possible exception to the general rule. But, since I haven't actually /used/ it myself (or tried to teach anyone with it), I can't honestly recommend it -- I /can/ (and do) say that it's looks promising but I can't claim from personal knowledge that it delivers on that promise. In the absence of a wide user-base for BlueJ, questions about what IDE a beginner should use will usually elicit a clamour of votes for peoples' own personal favourites -- and that list is unlikely to include BlueJ. So those of us that think that Eclipse, NetBeans, IntelliJ, et al, are bad learning tools will continue to try to balance the clamour with a blanket "no IDE" recommendation. > If you're interested, you can find it here: > > http://homepage.mac.com/mkolling/mrt/C54415237/E848832883/index.html One comment on that: Obviously I don't agree that the standard advice is "rubbish", but leaving that aside ;-) you've missed a reason for not using IDEs, or -- if you prefer -- you've missed a reason for using BlueJ in preference to a mainstream one. All the Java IDEs I've used or played with have the same problem -- they are focussed on the mechanics of producing code. They all emphasise syntax-colouring, code-completion, folding, and all the other claptrap. Stuff which has a lot to do with the mechanics of editing text, but nothing whatever to do with objects. And (IMO, anyway) the objects should be the programmer's primary focus -- /behaviour/ not code. If you add the code-centric attitude of the IDE to the already code-centric attitude that the Java language tends to promote (through the intricacy of its syntax and surface semantics) then it is hard for a programmer ever to get a feel for objects. And, IMO, that's a very serious problem indeed. When I looked at BlueJ some time ago, what I liked most about it was that its designers seemed to feel the same way, and were trying to bring the objects right into the foreground. That's why I suggested it might be a good place to start if the OP wasn't already happy working with objects. I hope that's still true, but just dropping in at <http://www.bluej.org/> to see what's new, I find Syntax colouring (14 May 2004) New extension: Checkstyle (14 May 2004) at the top of the News and Developments list -- not at all what I'd hoped for :-( Although, to be fair, the article behind the Syntax colouring headline does make a very good point. -- chris Chris, you have obviously put a lot of thought & experience into your post. Well done. > > > I, personally, use a plain text editor. The IDEs will generate lots > > > of code for you, but that doesn't help you learn what the code does. [quoted text clipped - 60 lines] > > -- chris > you have obviously put a lot of thought & experience into your post. You have apparently lost your delete key. For help, check here.. <http://www.physci.org/kbd.jsp?key=del> ;-) SignatureAndrew Thompson http://www.PhySci.org/ Open-source software suite http://www.PhySci.org/codes/ Web & IT Help http://www.1point1C.org/ Science & Technology ... > > I think this is very bad advice. > [quoted text clipped - 3 lines] > People tend to think that all IDEs are roughly the same except for different > ticks in their feature lists. I still have to disagree. The fact that people have misconceptions or are not fully informed about available IDEs does not make ignoring the most appropriate solutions good advice. ... > I mentioned BlueJ in my own reply to the OP, as a possible exception to the > general rule. But, since I haven't actually /used/ it myself (or tried to > teach anyone with it), I can't honestly recommend it -- I /can/ (and do) say > that it's looks promising but I can't claim from personal knowledge that it > delivers on that promise. Yes, you did mention BlueJ - and I am very happy about that. I have used it in my own teaching for seven years now (and I'm still using it) and I can only agree with your reasoning here. But then again - I am the designer of BlueJ, and I would, wouldn't I? > In the absence of a wide user-base for BlueJ, questions about what IDE a > beginner should use will usually elicit a clamour of votes for peoples' own > personal favourites -- and that list is unlikely to include BlueJ. BlueJ has downloads of about 40,000 a months and is used for teaching at least at 500 universities and training institutions around the world - that is a large enough user base to make some reasonably confident statements about it. And our experience generally is: teachers who have actually used BlueJ and another environment (and thus can make a first hand comparison) are usually the most devoted users of BlueJ. > > If you're interested, you can find it here: > > > > http://homepage.mac.com/mkolling/mrt/C54415237/E848832883/index.html > [...] you've missed a reason for not using > IDEs, or -- if you prefer -- you've missed a reason for using BlueJ in [quoted text clipped - 8 lines] > semantics) then it is hard for a programmer ever to get a feel for objects. > And, IMO, that's a very serious problem indeed. I couldn't agree more!!!! (Can't even decide how many exclamation marks I should shoot behind this...) I am aware that this is missing from that web page, while actually being the main argument. This was, in fact, the main goal at the beginning of the design of BlueJ. I think, essentially, we are on the same wavelength here. Regards, Michael > > People tend to think that all IDEs are roughly the same except for > > different [quoted text clipped - 3 lines] > are not fully informed about available IDEs does not make ignoring the > most appropriate solutions good advice. Fair enough. But | think my POV can be expressed by considering the hypothetical, but IMO quite plausible, response of an imaginary newcomer to Java (not a newcomer to programming, which is a different population). "Hmm, I'm told that BlueJ is good to start with." ....checks www.bluej.org... "Ah, this is a tool for beginners -- I'm no beginner, I don't need hand-holding, I want the Real Meat! BlueJ is like <insert IDE here>, only cut down for beginners, so I'll use <insert IDE here> instead of wasting time with a toy" I hope it's obvious that I /don't/ think BlueJ is a cut-down IDE, or a toy, but I can see how I might have thought that if I'd been starting out in Java today (with years of C++ behind me). > > In the absence of a wide user-base for BlueJ, questions about what IDE a > > beginner should use will usually elicit a clamour of votes for peoples' [quoted text clipped - 5 lines] > world - that is a large enough user base to make some reasonably > confident statements about it. That's very impressive! It makes it somewhat puzzling (I'm not being snide here) that it doesn't get mentioned more. I downloaded the latest version yesterday (40,001 downloads now ;-) and played with it for a couple of hours. Not a real test by any means, but I liked what I found. I'm quite likely to /use/ it for real code too. (I have some reservations about the editors handling of tabs and spaces, but I assume I can fettle that somehow). I wonder if the "problem" with BlueJ getting mindshare is that it isn't obvious that it /can/ be used for real code, so people use it for a while, and then think they /have/ to graduate to a "real" IDE to do real work. It obviously isn't suitable (the UI design) for handling large numbers of classes in a package -- but I'm not sure that large numbers of classes /should/ be in one package... Other than that I found the simplicity and absence of "fluff" appealing and effective. One thing I noticed is that BlueJ doesn't foreground the notion of package -- it puts stuff in the default package for instance. I can see that simplification is highly desirable for beginning (and perhaps not too talented) programmers -- a programming class as part of a normal school curriculum for example. But it isn't really appropriate for anyone who is already a programmer, and who wants to start Java -- the package concept is just too central to Java to be glossed-over. it took me some time to find how to put code into packages in BlueJ, and the process is more than a little tedious (error message telling me I have to create a package first instead of giving me the option to create one, not possible to move a class into a package from the UI -- drag-n-drop say -- you have to enter a package statement in the editor, no option to create a package for a project at the same time as the project itself, etc). I suggest an option to make BlueJ more package-friendly (similar to the way JUnit support can be activated). Perhaps too, an option to switch to a less hand-holding set of templates. The idea being that a user can at some /appropriate/ time (maybe straightaway, maybe never) switch BlueJ into a mode that is more suited to serious programming, and thus postpone the day when he or she has to start coping with the complexities of Eclipse, etc. I'm not trying to suggest that you should position BlueJ as anything but an educational IDE. But if I'm right in suspecting that people don't recommend BlueJ because their memory of it is as something they had to graduate from before the could be a "real" programmer, then a few /optional/ tweaks to the UI might help you gain mindshare in the "pro" community. Or maybe the community is just too obsessed with complexity... > I think, essentially, we are on the same wavelength here. So it seems. I think I shall add BlueJ to my recitation of the "standard advice" from now on. -- chris > > > I, personally, use a plain text editor. The IDEs will generate lots > > > of code for you, but that doesn't help you learn what the code does. [quoted text clipped - 11 lines] > much difference between them (on this issue) then the advice would be more > specific. I disagree - I think that general advice is incorrect in many cases. A good ide like IDE or Eclipse can help a student stay focussed on objects, rather than syntax. If you are trying to teach a language, or use it in a teaching situation, you have a lot of choices about presentation. In the main, though, you have a very limited number of facts that you can slip in to the lesson, without overwhelming your students. Thus, you have to pick and choose. Learning javac, directories, jar files and command syntax, and the like can be useful, and will be important to a student eventually. Given a choice, though, between a student thinking about the proper methods for their class, and thinking about the proper directory layout to make javac happy, I want them thinking about the object and its behavior, not the mechanics of the command line tool. [...] > They all emphasise syntax-colouring, code-completion, folding, and all the > other claptrap. Stuff which has a lot to do with the mechanics of editing [quoted text clipped - 4 lines] > surface semantics) then it is hard for a programmer ever to get a feel for objects. > And, IMO, that's a very serious problem indeed. To me, you learn best by doing. Thus, the best way to learn how to write decent classes is to write some, and then go through a critique. I would rather they spend much of their early time thinking about the result, rather than the process of getting there. I want students to bang out a lot of code, with enough feedback so they can see what good classes look like. If they can see the ideas I am trying to get across in many contexts, they are more likely to see the meaning behind the syntax. If syntax coloring makes them familiar with what Java code should look like syntacticly before we delve into the details, I am happy. They will need the details, no way around it, but having the editor get them started is a big help. Put another way - in the early stages of learning a language or library, there are a lot of facts to pick up. A good ide hides some of that complexity. You will need to learn it eventually, which is why I also get them using ANT fairly quickly, but I want their first Java efforts to be pointed at the classes and what that means, rather than at the mechanics. Let an IDE make those mechanics easier during the early stages, so that they stay focussed not on code, but on solving their problems with it. Scott > Put another way - in the early stages of learning a language or > library, there are a lot of facts to pick up. A good ide hides [quoted text clipped - 5 lines] > stay focussed not on code, but on solving their problems with > it. The only problem I see with this approach is that you've set the expectation that they won't need to know it. Alot of them will spend the rest of their programming lives staying away from the guts because their first taste was with something that "just worked". Why should I have to do that work? Then, in the middle of a development effort, their IDE craps out, doesn't support something, the admin guy is on vacation, ... and they are SOL. Sort of like most java programmers I run across that code against databases. Somebody at a beginning java class spouted "Database Independence" and three years into their career, they still can't code a "group by", and the "Database Independence" translated to "Database Ignorance". SignatureGalen Boyer > I disagree - I think that general advice is incorrect in many cases. A > good ide like IDE or Eclipse can help a student stay focussed on > objects, rather than syntax. I don't agree with this in general, but I think I've already made my point as clearly as I can. I just wanted to reply to a couple of specifics. > Learning javac, directories, jar files and command syntax, and the like > can be useful, and will be important to a student eventually. I take it as starting point that command line, directories, and files are understood. If that's not the case then it's something that has to be fixed independently of, and before, learning Java. Jar files now, are something else. I think that I'd recommend ignoring them entirely as an "advanced" topic that is not needed (and indeed hinders) basic understanding. I'd suggest to any beginner, experienced programmer or not, that (if they aren't using BlueJ ;-) they set their classpath to point to /one/ directory, and that they compile with the options to put the output into that directory always (use a shell script to compile). That's how I started out (though it took me some time to work out that that was a good way of working because there's no guidance on how to keep things /simple/ in the Java world, complexity-obsessed as it is). It's surprising just how very effective that settup is. I'm still using essentially the same thing now... > To me, you learn best by doing. Thus, the best way to learn how to > write decent classes is to write some, and then go through a critique. > I would rather they spend much of their early time thinking about the > result, rather than the process of getting there. I don't entirely agree. I think the best way (or an important part of it) to learn how to write decent classes is to interact with their instances. Yes, I agree that practise in writing *lots* of classes is a very, very, good thing, and of course the value of critique (if it's available) is inestimable. But if you haven't worked in an environment where you are always in touch with your objects, then you probably don't realise how enlightening that experience is. Of course, running from the command-line isn't "being in touch with the objects" either but at least the tools don't get in the way. > Put another way - in the early stages of learning a language or library, > there are a lot of facts to pick up. A good ide hides some of that [quoted text clipped - 4 lines] > stages, so that they stay focussed not on code, but on solving their > problems with it. But -- with the exception of BlueJ -- I just don't agree that the current crop of IDEs do that. They /could/, but they don't. They just give you another layer of complexity, another tool to learn, and another distraction from the task at hand. I guess we just disagree ;-) -- chris > I mentioned BlueJ in my own reply to the OP, as a possible exception to the > general rule. But, since I haven't actually /used/ it myself (or tried to > teach anyone with it), I can't honestly recommend it -- I /can/ (and do) say > that it's looks promising but I can't claim from personal knowledge that it > delivers on that promise. As someone who is using BlueJ, has been taught using BlueJ, and has taught others using BlueJ, I feel it's a very good tool for the job. Of course, I have an obvious bias, but what can I do? :) -Hank > I have been a professional programmer for about 14 years on MVS, HP-UX, and > Windows. I have been following Java since about 1997, but I have never done > any app development in it. Here are my questions: > > 1. Where do the gurus go to get programming information? A newsgroup, > website, what? Over the years, I've noticed I get the most programming knowledge out of books I've borrowed or bought (mostly bought), followed closely by the internet docs. The reason is probably because books provide a much more structured approach to learning, whereas most internet docs are either too short and hasty, or scattered. Some sites that might be useful for what books to buy: Amazon.com actually has a Java section all to itself: http://www.amazon.com/exec/obidos/tg/browse/-/3608/ref=br_bx_c_2_0/002-5868930-0 098408 Also, I just found this http://www.javashelf.com/ > 2. What is the best freeware IDE, and what is the best professional IDE? Someone already gave a good list for general IDEs (eclipse, netbeans, etc). But if you're thinking of doing any J2ME work, and using stuff beyond the J2ME Wireless Toolkit, then here are some more: http://www.microjava.com/articles/techtalk/ide IBM's Websphere Studio Device Developer is awesome because it allows development beyond just Midlets into CDC profiles for handhelds and more powerful smartphones: http://www-306.ibm.com/software/wireless/wsdd/ > 3. If you were a professional programmer like me who wanted to get up to > speed quickly, what resources would you use? depends on what niche of java you're going to get into, eh. server-side? mobiles and other pervasive devices? smartcards? desktop and gui (gasp!)? probably for general purposes, i quick stop at javasoft.com would be warranted, then head over to javaranch.com for newcomers... > Thank you very much for your time. no problem. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.