 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / June 2005Do we have educational IDEs?
I have seen number of scenes where IDEs are nothing but serious stumbling blocks for Java programming beginners. I think that is because, basically, IDE is designed as a tool for professional, not a learning aid. But, if their main career tool should be an IDE when they became a young professional, I feel IDEs with some educational cares implemented should be preferred to a plain editor and command line compiling cycles. What is your opinion about this? And, do we already have IDEs for educational purposes? > I have seen number of scenes where IDEs are nothing but serious > stumbling blocks for Java programming beginners. I think that is [quoted text clipped - 8 lines] > What is your opinion about this? And, do we already have IDEs > for educational purposes? Eclipse 3.1 is a very helpful IDE. It has smart completion suggestion menus, realtime syntax checking, automatic background compilation, detailed error reporting with menus of suggested fixes, class hierarchy mapping, JavaDoc tooltips, refactoring, reference and implementation searching, generation of delegation methods, and local and remote debugging. It's free, open source, and cross platform. The only cost of using it is that it needs a very powerful system to be responsive. > And, do we already have IDEs > > for educational purposes? > > Eclipse 3.1 is a very helpful IDE. It has [list of features deleted] It is also huge, confusing, full of "advanced" features, and is completely lacking in features that would help anyone to learn (with the arguable exception of auto-completion). IMO it is not even /slightly/ suitable for beginners[*]. For the OP, BlueJ /is/ designed for beginners. More specifically, it is designed for use by people who are learning to program, and learning how to think OO. I've never taught, with or without BlueJ, so I can't recommend it from personal experience, but the approach they take looks extremely promising to me. -- chris ([*] I'm not so sure that it's particularly suitable for anyone else either. I use it myself -- as the least bad option available within my budget -- but I don't like it much) > > Eclipse 3.1 is a very helpful IDE. It has [list of features deleted] > > It is also huge, confusing, full of "advanced" features, and is completely > lacking in features that would help anyone to learn (with the arguable > exception of auto-completion). IMO it is not even /slightly/ suitable for > beginners[*]. IMO auto-complete is responsible for more poor programmers than any other single feature of modern IDEs. When you're starting out you learn by getting it wrong and it interferes with that. I'm still to be convinced there is a suitable replacement for an decent editor (like <plug>JEdit</plug>) and Sun JDK. These skills can be applied anywhere later on.  Signature[Ross A. Bamford] [ross AT the.website.domain] Roscopeco Open Tech ++ Open Source + Java + Apache + CMF http://www.roscopec0.f9.co.uk/ + info@the.website.domain > IMO auto-complete is responsible for more poor programmers than any > other single feature of modern IDEs. When you're starting out you learn > by getting it wrong and it interferes with that. I'm inclined to agree, but it does depend on a number of factors. For instance, the Java class library is pretty huge, and it just isn't possible to learn enough of it for any of it to make sense in isolation, until /after/ you've done some programming -- but how to do that programming if you know nothing about the class library ? Autocomplete /may/ (IMO) help to get over that stage by, in effect, providing training wheels for the wobbling programmer-to-be. > I'm still to be convinced there is a suitable replacement for an decent > editor (like <plug>JEdit</plug>) and Sun JDK. These skills can be > applied anywhere later on. Where the <insert editor of choice here> + JDK approach fails (or rather, where it risks failure) is that it doesn't teach /objects/. If all you are doing is writing code, then it's unlikely that you'll ever think about anything except code. The BlueJ IDE is uniquely (in the Java world) aimed at teaching OO by providing "real" access to live objects. That (IMO) makes a difference in kind. I'm reluctant to claim too much for BlueJ because -- although I know what an enormous difference it makes to work with live objects -- I'm not entirely convinced that BlueJ does provide an experience of objects that's rich /enough/, although they've certainly done a reasonable job within limits set by the JVM. -- chris > > IMO auto-complete is responsible for more poor programmers than any > > other single feature of modern IDEs. When you're starting out you learn [quoted text clipped - 7 lines] > that stage by, in effect, providing training wheels for the wobbling > programmer-to-be. Well, definitely, but I've met too many programmers who automatically type their identifier, wait for the method list, scroll to the method, insert, wait for the variables, etc. Perhaps an IDE that supports auto-complete, but only gives the user a limited number of uses, a "three completes and you're out" rule :) > Where the <insert editor of choice here> + JDK approach fails (or rather, where > it risks failure) is that it doesn't teach /objects/. If all you are doing is > writing code, then it's unlikely that you'll ever think about anything except > code. The BlueJ IDE is uniquely (in the Java world) aimed at teaching OO by > providing "real" access to live objects. That (IMO) makes a difference in > kind. This intrigues me, I'm off to have a look :) Cheers, Ross Signature[Ross A. Bamford] [ross AT the.website.domain] Roscopeco Open Tech ++ Open Source + Java + Apache + CMF http://www.roscopec0.f9.co.uk/ + info@the.website.domain Chris Uppal coughed up: >> IMO auto-complete is responsible for more poor programmers than any >> other single feature of modern IDEs. When you're starting out you [quoted text clipped - 7 lines] > Autocomplete /may/ (IMO) help to get over that stage by, in effect, > providing training wheels for the wobbling programmer-to-be. Possibly. The biggest problem with the class library is not its size per se IMO, but the fact that the old ways and new ways of doing things are sitting side by side and intertwined to a horrible degree. Furthermore, sometimes the "old ways" have not reached the point of deprecation, so the user has very little chance of knowing which way to go. I don't see any kind of autocompletion solving that problem. >> I'm still to be convinced there is a suitable replacement for an >> decent editor (like <plug>JEdit</plug>) and Sun JDK. These skills [quoted text clipped - 14 lines] > > -- chris Signature"So I just, uh... I just cut them up like regular chickens?" "Sure, just cut them up like regular chickens." >> And, do we already have IDEs >> > for educational purposes? [quoted text clipped - 22 lines] > I > don't like it much) I've been teaching with BlueJ. I and the students like it very much. It's free. Take a look: http://www.bluej.org/ Chris Uppal coughed up: >> And, do we already have IDEs >>> for educational purposes? [quoted text clipped - 5 lines] > the arguable exception of auto-completion). IMO it is not even > /slightly/ suitable for beginners[*]. RIght---not even slightly so. You left out the fact that it is a quickly moving target to boot, but that by itself is not a sin. Actually, I've been mystified by eclipse since its very beginning. So popular has this thing been that I've had to force myself to use it to see if there really is something that I was missing. I've hated it from the beginning till now, and every stinking day in between, but am so afraid that I must be missing something that I still use /only/ either it or a non-IDE vi-javac-java-repeat cycle. I have to say that in all this time, and I've used many different IDE's over the years, that eclipse is the least friendly and least intuitive of the lot. What I've discovered though is that when I raise such complaints, even with complete examples as to why I find it hard to understand (not just over usenet---conversationally as well), I am often met with a large emotional response. Eclipse, has somehow won over the /hearts/ of the engineers using it. > For the OP, BlueJ /is/ designed for beginners. More specifically, it > is designed for use by people who are learning to program, and [quoted text clipped - 7 lines] > either. I use it myself -- as the least bad option available within > my budget -- but I don't like it much) SignatureEverythinginlifeisrealative.Apingpongballseemssmalluntilsomeoneramsitupyournose. Thomas G. Marshall wrote on 05.05.2005 17:21: > Actually, I've been mystified by eclipse since its very beginning. So > popular has this thing been that I've had to force myself to use it to see [quoted text clipped - 9 lines] > usenet---conversationally as well), I am often met with a large emotional > response. I can understand that. My primary IDE is NetBeans and I'm giving Eclipse a try every now and then. Each time I dump it after several attempts to use it. I feel it's utterly complex and disturbing to use. It might be because I'm used to NetBeans and I can't get the right way of using Eclipse Thomas > Actually, I've been mystified by eclipse since its very beginning. So > popular has this thing been that I've had to force myself to use it to [quoted text clipped - 9 lines] > friendly > and least intuitive of the lot. So I'm not the only one? I too have tried several times to get into Eclipse without ever getting hooked. People tell me of its great features but I've never seen them because I've usually uninstalled it within 15 minutes of firing it up because using it makes me angry. NetBeans would be OK if it had a more intelligent editor, decent code-generation (getters, setters, constructors, etc.), better refactoring and wasn't so slow. Compare these to IDEA, which is powerful, fast and very helpful without getting in the way, and it's clear that sometimes you do get what you pay for. Dan. SignatureDaniel Dyer http://www.footballpredictions.net "Thomas G. Marshall" <tgm2tothe10thpower@replacetextwithnumber.hotmail.com> wrote: [snip] >Actually, I've been mystified by eclipse since its very beginning. So >popular has this thing been that I've had to force myself to use it to see [quoted text clipped - 11 lines] > >Eclipse, has somehow won over the /hearts/ of the engineers using it. I agree, but then I feel exactly the same way about vi. David Segall coughed up: > "Thomas G. Marshall" > <tgm2tothe10thpower@replacetextwithnumber.hotmail.com> wrote: [quoted text clipped - 17 lines] >> Eclipse, has somehow won over the /hearts/ of the engineers using it. > I agree, but then I feel exactly the same way about vi. Funny, I have no such feeling about vi. I do have almost *PRECISELY* the same feeling about emacs. That was an editor I just could not get "comfortable" with. Tried---then gave up and vi'ed everything (and saved my left pinky from destruction, from what others have told me). And now that I think about it, I had very similar complaints with emacs 20 years ago that I have now with Eclipse. Emacs was essentially a /tower/ of rogue features. SignatureForgetthesong,I'dratherhavethefrontallobotomy... "Thomas G. Marshall" <tgm2tothe10thpower@replacetextwithnumber.hotmail.com> wrote: >David Segall coughed up: >> "Thomas G. Marshall" [quoted text clipped - 27 lines] >years ago that I have now with Eclipse. Emacs was essentially a /tower/ of >rogue features. >Chris Uppal coughed up: > [quoted text clipped - 21 lines] >Eclipse, has somehow won over the /hearts/ of the engineers using it. > Being a [somewhat] noob to Java2 (with past experience in other OO languages, however), I have thus far found Eclipse to be quite useful. Of course, I started with the cmd line approach as all beginners should, I believe, but naturally I reached the point of frustration with the switching windows, typing multiple commands, etc. I needed something quick and *easier* than all the bs with a cmd line. Surely I'm not aware of all the "features" of Eclipse, nor am I sure I ever will be, but obviously I would choose the quick integrated approach over the tedious cmd line. But maybe that's just me... > quick and *easier* than all the bs with a cmd line. Surely I'm not > aware of all the "features" of Eclipse, nor am I sure I ever will be, > but obviously I would choose the quick integrated approach over the > tedious cmd line. But maybe that's just me... No, I jumped directly to IDEs as well - never even started with the cmd line. SignatureJosef Garvi "Reversing desertification through drought tolerant trees" http://www.eden-foundation.org/ new income - better environment - more food - less poverty > Actually, I've been mystified by eclipse since its very beginning. So > popular has this thing been that I've had to force myself to use it to see [quoted text clipped - 4 lines] > used many different IDE's over the years, that eclipse is the least friendly > and least intuitive of the lot. And I have been equally mystified by those that don't like Eclipse. It is a great IDE and one that I couldn;t live without. I have heard that IntelliJ is slightly better, but not significantly enough to warrant the price. But I must say that I do not do J2EE development so can't speak to that. But even then it is certainly better than the command line tools. > What I've discovered though is that when I raise such complaints, even with > complete examples as to why I find it hard to understand (not just over > usenet---conversationally as well), I am often met with a large emotional > response. > > Eclipse, has somehow won over the /hearts/ of the engineers using it. With very good reason. SignatureDale King >I have seen number of scenes where IDEs are nothing but serious > stumbling blocks for Java programming beginners. I think that is [quoted text clipped - 8 lines] > What is your opinion about this? And, do we already have IDEs > for educational purposes? Yes, BlueJ. I'm learning Java2 using JCreator (www.jcreator.com) The LE version is free, written in C++ and so is responsive. It's nice easy and straightforward - just what I need when I'm learning. I did download the netBeans things initially - had no idea what I was doing - scared me to death. Jcreator and no doubt the other suggestions in this thread are ideal to learn with. HTH Steve > What is your opinion about this? And, do we already have IDEs > for educational purposes? Steve Reeves coughed up: > I'm learning Java2 using JCreator (www.jcreator.com) > [quoted text clipped - 3 lines] > I did download the netBeans things initially - had no idea what I was > doing - scared me to death. :) lol. Welcome to the world of applications that violate the law of least surprise. I don't know much about netBeans honestly, but I would suggest that you stay *far* away from eclipse for the time being. > Jcreator and no doubt the other > suggestions in this thread are ideal to learn with. [quoted text clipped - 4 lines] >> What is your opinion about this? And, do we already have IDEs >> for educational purposes? Signature"His name was Robert Paulson. His name was Robert Paulson. His name was Robert Paulson..." > I have seen number of scenes where IDEs are nothing but serious > stumbling blocks for Java programming beginners. I think that is [quoted text clipped - 8 lines] > What is your opinion about this? And, do we already have IDEs > for educational purposes? I am one of these people you deeply believe that people should learn the basics. This includes handling an editor, a compiler and some build files. I deeply mistrust "programmers" who can't even find a compiler command line switch. It is for the same reason I don't trust craftsmen who don't know how to handle basic tools of their trade. My car doesn't get serviced by someone who can't handle a screwdriver but does everything exclusively with an air wrench, does yours? I am not saying that IDEs are bad, just that a career-programmer should know more than just how to click in an IDE. /Thomas SignatureThe comp.lang.java.gui FAQ: ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq ... > I am one of these people you deeply believe that people > should learn the basics. This includes handling an > editor, a compiler and some build files. I deeply > mistrust "programmers" who can't even find a compiler > command line switch. ... The problem with this is deciding the limits of "the basics". For example, you don't include assembly language programming. Why not? It certainly contributes to a deeper understanding of programming than writing only in a high level language. What are your criteria for selecting "the basics"? Patricia > ... >> I am one of these people [who] deeply believe [quoted text clipped - 10 lines] > programming than writing only in a high level > language. Plug board wiring, keypunch machines and card sorters. If that was good enough for Grace Hopper to learn on, it ought'a be good enough for you! ;-) Patricia Shanahan coughed up: > ... >> I am one of these people you deeply believe that people [quoted text clipped - 13 lines] > > Patricia Assembler programming on a no-frills 8-bit machine like the 6502. That will teach you not to gobble up memory unnecessarily, and to worry about how much time every little bit of your code takes. Signature"His name was Robert Paulson. His name was Robert Paulson. His name was Robert Paulson..." In article <GGcge.1462$rw4.462@trndny03>, "Thomas G. Marshall" <tgm2tothe10thpower@replacetextwithnumber.hotmail.com> proposed: > Patricia Shanahan coughed up: > > ... [quoted text clipped - 18 lines] > teach you not to gobble up memory unnecessarily, and to worry about how much > time every little bit of your code takes. Emulators for the 6502 are widely available for many popular architectures, making this an excellent choice. Several are open source. http://www.google.com/Top/Computers/Emulators/Apple/Apple_II/ SignatureJohn jmatthews at wright dot edu www dot wright dot edu/~john.matthews/ > I am one of these people you deeply believe that people should learn the > basics. This includes handling an editor, a compiler and some build > files. I deeply mistrust "programmers" who can't even find a compiler > command line switch. > > It is for the same reason I don't trust craftsmen who don't know how to > handle basic tools of their trade. My car doesn't get serviced by > someone who can't handle a screwdriver but does everything exclusively > with an air wrench, does yours? What you say is true. However, it misses the point. When talking about educational IDEs, the issue is what you should see first when you start out. It is not about the complete set of skills that you should aquire before you are finished. I would also hope that every professional programmer knows several different languages from different paradigms. Does that mean that we have to teach them several languages from different paradigms all from the start? Education is very much about deciding how and in what order to teach things. That's the harder question than the "what". Educational theory favours teaching the important "big ideas" first, and filling in the details later. "Objects" is a big idea. "Command line switch" is a detail. If I'm an employer looking for a Java programmer, and I have one candidate who understands objects, but does not know Java's command line switches (maybe because he's only done C++ or Smalltalk or Eiffel), that might be okay. If someone knew all the command line switches backwards, but doesn't understand objects, there's no way I would let him anywhere near my code. When we talk about educational IDEs, we talk not about what you should learn in total, but what you should learn /first/. Regards, Michael > I have seen number of scenes where IDEs are nothing but serious > stumbling blocks for Java programming beginners. I think that is [quoted text clipped - 8 lines] > What is your opinion about this? And, do we already have IDEs > for educational purposes? BlueJ was written explicitly for teaching java language and OO thinking. It does what's needed but is simple enough that it doesn't "get in the way". Have a look at their web site www.bluej.org. Steve Personally, I favor a simple text editor like JEdit and the command line for novices. For an educational IDE, take a look at Dr. Java or BlueJ. > Personally, I favor a simple text editor like JEdit and the command > line > for novices. Very bad idea. Using the command line tools requires you to understand concepts that you don't have the proper frame of reference to understand until you get a good footing in the language. Try explaining what a class path is when the person doesn't even understand what a class is. Everyone should learn the command line tools, BUT not until you know the language. They also make the statement that using an IDE requires learning the IDE on top of the language. Well the fallacy here is the notion that the command line tools are not a development environment. They are a DE as much as an IDE and reauire more learning than something like BlueJ. Many who advocate command line tools actually believe that the command line flags are part of the language. Quoting John Bollinger from a couple of months ago, "IDEs do a good job of hiding many of the nuts and bolts of language usage". That is incorrect. The command line tools are not part of the language. I don't see them defined in the JLS. Are you using a different language if you compile with jikes instead. The language is what is in the compilation units. I know of no IDE that hides any of the language (unless you want to count code folding). The other crucial part that you leave out with your command line tools is a decent debugger, which is a valuable tool for a newbie to be able to step through the code to see what happens. > For an educational IDE, take a look at Dr. Java or BlueJ. BlueJ is definitely the right choice for learning the language. SignatureDale King > > Personally, I favor a simple text editor like JEdit and the command > > line [quoted text clipped - 3 lines] > concepts that you don't have the proper frame of reference to understand > until you get a good footing in the language. Put the file in the current directory and type. % javac HelloWorld.java % java HelloWorld Could you clarify why this is such a bad idea? How is this conceptually more difficult than using an IDE? > They also make the statement [snipped] > Many who advocate command line tools [snipped] I didn't advocate such things. If anything, I'm arguing for *less* tools, projects, and cruft for novices to sift through. > The other crucial part that you leave out with your command line tools > is a decent debugger, which is a valuable tool for a newbie to be able > to step through the code to see what happens. I agree a debugger is a useful tool, but it is another layer of abstraction. When starting out, System.out.println() can take you pretty far. Eventually students should learn higher level tools, but my preference is to defer it until after they've learned a little programming. I certainly don't claim this is the only right way to do it, just one that has worked extremely well in my experience. > BlueJ is definitely the right choice for learning the language. As I said, BlueJ is fine choice for some folks (especially if the focus is OOP). Whether it's "definitely the right choice" depends on the context. A basic text editor and command line are easy to explain, easy to learn, and are skills that are, for the most part, programming language independent. googmeister@gmail.com coughed up: ...[rip]... >> BlueJ is definitely the right choice for learning the language. > [quoted text clipped - 3 lines] > easy to learn, and are skills that are, for the most part, > programming language independent. Yes, and even /if/ BlueJ is the end-all answer to teaching java and OOP in general, I /still/ would want the user to feel as if he understands /how to use/ the java sdk as shipped. IDE's just remove the user too far from the nitty gritty, particularly IDE's that remove the concept of the file and just allow you to create classes. SignaturePuzzle: You are given a deck of cards all face down except for 10 cards mixed in which are face up. If you are in a pitch black room, how do you divide the deck into two piles (may be uneven) that each contain the same number of face-up cards? Answer (rot13): Sebz naljurer va gur qrpx, qrny bhg gra pneqf naq syvc gurz bire. > googmeister@gmail.com coughed up: > [quoted text clipped - 5 lines] >>focus is OOP). Whether it's "definitely the right choice" depends on >>the context. A basic text editor and command line are easy to explain, Not as easy as BlueJ. >>easy to learn, and are skills that are, for the most part, >>programming language independent. How to invoke the compiler and run the program are definitely NOT progr. lang. independent. > Yes, and even /if/ BlueJ is the end-all answer to teaching java and OOP in > general, I /still/ would want the user to feel as if he understands /how to > use/ the java sdk as shipped. IDE's just remove the user too far from the > nitty gritty, particularly IDE's that remove the concept of the file and > just allow you to create classes. No one has claimed that BlueJ would make them understand how to use the SDK. How to use the SDK has to be taught as well. The issue is that it is best to teach it after learning the language and learning the language is best done using tools that remove those nitty-gritty details that they won't understand. SignatureDale King >>>Personally, I favor a simple text editor like JEdit and the command >>>line [quoted text clipped - 17 lines] > Could you clarify why this is such a bad idea? How is this conceptually > more difficult than using an IDE? Just take a sampling of posts in comp.lang.java.help and see how often someone has trouble doing just that. Some common problems: - Is the JDK/bin in the path? - Do you have a classpath set that doesn't include the current directory. - People often type java HelloWorld.class which presents non-intuitive error message. - Imagine if the student finds some code and wants to try to run it using this technique. Except that the file has a package statement in it. I pity the poor person trying to get that to work with only the knowledge you have given him. - Eventually you need to start using packages which is much more complicated. You will have to give him new instructions which will seem to contradict what you gave him before. - You probably eventually need to use other libraries. E.g. class situations often have their own set of utility classes to hide some nitty gritty details of the Java API. Once again you have to change the directions for building. I could go on, but I think that is a good list. SignatureDale King Dale King coughed up: >>>> Personally, I favor a simple text editor like JEdit and the command >>>> line [quoted text clipped - 39 lines] > > I could go on, but I think that is a good list. ....which IMO doesn't make a point one way or another. I could show you a huge list of people asking about the language itself, which would equally make no point. Signature"Well, ain't this place a geographical oddity! Two weeks from everywhere!" > Dale King coughed up: > [quoted text clipped - 43 lines] > > .....which IMO doesn't make a point one way or another. It makes a point that running the command line tools is not as straight forward as those who oppose an IDE would have you believe. There are many pitfalls. And the newbie has no way to figure it out since all he is doing is doing what he is told but doesn't understand. > I could show you a > huge list of people asking about the language itself, which would equally > make no point. It makes no point in this discussion. Most of those questions are related to preconceived notions from other languages or the failure of the poster to even try to educate themself. In the case I'm talking about the newbie has little chance of educating himself without a knowledge of the language. SignatureDale King Dale King coughed up: >> Dale King coughed up: >> [quoted text clipped - 46 lines] > It makes a point that running the command line tools is not as > straight forward as those who oppose an IDE would have you believe. It doesn't make that point. Without a count of the folks that have no confusion with issue X the number of people who /do/ have a confusion has no meaning. > There are many pitfalls. And the newbie has no way to figure it out > since all he is doing is doing what he is told but doesn't understand. I know what you're saying here, but it still doesn't jive with my set of intuitions. "Doing what he is told but doesn't understand" doesn't make the case to not tell them. It makes the case to tell them but make them /understand/ it. >> I could show you a >> huge list of people asking about the language itself, which would [quoted text clipped - 5 lines] > about the newbie has little chance of educating himself without a > knowledge of the language. SignatureIt's time for everyone to just step back, take a deep breath, relax, and stop throwing hissy fits over crossposting. > Dale King coughed up: > [quoted text clipped - 52 lines] > confusion with issue X the number of people who /do/ have a confusion has no > meaning. It is an existence proof. All I have said is that there exists people who will have trouble with the command line tools that will impeded learning. I make no claims about the what percentage so I fail to see how a count of how many people don't have a problem. I certainly agree that the majority of people will do fine with the command line tools but there are some that don't and the volume and types of traffic from those people indicates that it is not an insignificant number and that it cannot be attributed to the fault of the person asking the question. >>There are many pitfalls. And the newbie has no way to figure it out >>since all he is doing is doing what he is told but doesn't understand. [quoted text clipped - 3 lines] > case to not tell them. It makes the case to tell them but make them > /understand/ it. An once again I never said don't tell them. If you want to make them understand it, it is a heck of a lot easier once they understand the language. And understanding the command line tools has no benefit for learning the language. SignatureDale King Dale King coughed up: >> Dale King coughed up: >>>> Dale King coughed up: ...[rip]... >>>>> I could go on, but I think that is a good list. >>>> [quoted text clipped - 11 lines] > learning. I make no claims about the what percentage so I fail to see > how a count of how many people don't have a problem. Yes you did. Above you said about that list of people: Dale King: It makes a point that running the command line tools is not as straight forward as those who oppose an IDE would have you believe. A simple existance proof does not even attempt to make that point. Put another way, if you show me 30 people with that problem in the last 6 months, if there 30,000 that did not have the problem, then you are talking about a .1% of the folks having trouble and pretending that it means something. You also reacted to my paragraph elsethread this way: Thomas G. Marshall: Usually, when teaching a new language, I (or everyone else I know who has taught anything), starts off with how to get something akin to the hello world example to run. Even when I teach folks with an IDE, I go through the steps needed to configure, compile and run a HW app. Dale King: The plethora of posts in these groups from helpless newbies trying to get hello world to run pretty much proves that your statements are wrong. What you're establishing here is *NOT* an existance proof. You are counterring my statements specifically. You are trying to draw a conclusion from the number of posts you found "from helpless newbies trying to get hello world to run". I think we're done here. Thanks again for the discussion. SignatureFramsticks. 3D Artificial Life evolution. You can see the creatures that evolve and how they interact, hunt, swim, etc. (Unaffiliated with me). http://www.frams.alife.pl/ > Dale King coughed up: > [quoted text clipped - 26 lines] > line tools is not as straight forward as those > who oppose an IDE would have you believe. And it still makes that point very well. I gave a list of pitfalls when googmeister asked how is that harder than an IDE and pointed to the lists to show that those are not just hypothetical problems people have. People post here pretty much everyday with those very problems. > A simple existance proof does not even attempt to make that point. Put > another way, if you show me 30 people with that problem in the last 6 > months, if there 30,000 that did not have the problem, then you are talking > about a .1% of the folks having trouble and pretending that it means > something. And what percentage does it have to before we quit claiming that the command line tools are the best way to learn? I've been in these groups for the last 8 years and there has easily been thousands of posts from those that can't run a simple app. I'm not ready to just discount those people. > You also reacted to my paragraph elsethread this way: > [quoted text clipped - 12 lines] > > What you're establishing here is *NOT* an existance proof. Nor did I say it was. > You are counterring my statements specifically. You are trying to draw a conclusion > from the number of posts you found "from helpless newbies trying to get > hello world to run". In large threads posts seem to blur together and you end up responding to more than the statement quoted. I agree that my statement is slightly overstated (prove was a bit to strong a word), but not the conclustion. And the conclusion is that starting with hello world is not necessarily the best place to start. You can read some papers on it at the BlueJ site that support that opinion. The best way to teach the language and OO development (and I would argue that teaching OO is actually the more important goal than just the language) is to start with objects. You might want to check out the book "Objects First with Java - A Practical Introduction using BlueJ" which is linked from the home page of BlueJ. SignatureDale King > The other crucial part that you leave out with your command line tools > is a decent debugger, which is a valuable tool for a newbie to be able > to step through the code to see what happens. There are some educators that feel using a debugger can be detrimental to learning good programming techniques in school. Here is what one very respected author has to say. <http://www.skylit.com/javamethods/nodebugger.html> >> For an educational IDE, take a look at Dr. Java or BlueJ. You might also take a look at Jurtle, my educational IDE. The tutorial is designed more for independent study rather than classroom use, but many teachers are using the IDE (and its built-in Turtle Graphics) in the classroom. > BlueJ is definitely the right choice for learning the language. SignatureBill Tschumy Otherwise -- Austin, TX http://www.otherwise.com >>The other crucial part that you leave out with your command line tools >>is a decent debugger, which is a valuable tool for a newbie to be able [quoted text clipped - 5 lines] > > <http://www.skylit.com/javamethods/nodebugger.html> There are also those that claim the earth is flat. Doesn't mean they're right. A debugger is invaluable for letting a newbie see what is happening. You can teach polymorphism, but how much better to also show him that when I step into this method it actually goes to the subclass' method not the superclass, etc. SignatureDale King >>> The other crucial part that you leave out with your command line tools >>> is a decent debugger, which is a valuable tool for a newbie to be able [quoted text clipped - 8 lines] > There are also those that claim the earth is flat. Doesn't mean they're > right. So now anyone who disagrees with you is the equivalent of a "flat earther"? The issue is not cut and dry (IMO). My point is some instructors think debuggers are a hinderance at the early stages of learning to program. > A debugger is invaluable for letting a newbie see what is happening. You > can teach polymorphism, but how much better to also show him that when I > step into this method it actually goes to the subclass' method not the > superclass, etc. It is also another thing to get in the way. SignatureBill Tschumy Otherwise -- Austin, TX http://www.otherwise.com > The issue is not cut and dry (IMO). My point is some instructors think > debuggers are a hinderance at the early stages of learning to program. My experience is that they are a hinderance in the later stages, after learning to program. It can inhibit better general understanding of the code. Look at your code first to find a problem before jumping to a debugger. SignatureLee Fesperman, FFE Software, Inc. (http://www.firstsql.com) ============================================================== * The Ultimate DBMS is here! * FirstSQL/J Object/Relational DBMS (http://www.firstsql.com) >>The issue is not cut and dry (IMO). My point is some instructors think >>debuggers are a hinderance at the early stages of learning to program. > > My experience is that they are a hinderance in the later stages, after learning to > program. It can inhibit better general understanding of the code. Look at your code > first to find a problem before jumping to a debugger. better yet, use write a (failing) unit test first and then make it pass (i.e. TDD). Then you never (well 99.9% of the time) have to use the debugger. >> The issue is not cut and dry (IMO). My point is some instructors think >> debuggers are a hinderance at the early stages of learning to program. [quoted text clipped - 4 lines] > your code > first to find a problem before jumping to a debugger. With Java, I'll agree with you. I never use a debugger in Java. The kinds of problems where debuggers are most useful to me (pointer arithmetic, array bounds overruns) just don't happen in Java. Well, I guess array bounds problems do happen, but you are immediately told what the problem is. In almost all cases, give me a few printlns in Java and I will be happy. When I did lots of C programming, debuggers would save my life. SignatureBill Tschumy Otherwise -- Austin, TX http://www.otherwise.com > >> The issue is not cut and dry (IMO). My point is some instructors think > >> debuggers are a hinderance at the early stages of learning to program. [quoted text clipped - 10 lines] > In almost all cases, give me a few printlns in Java and I will be happy. > When I did lots of C programming, debuggers would save my life. Yep, I've never used a debugger with Java, just println and a special thread profiler once. I used a debugger with C/C++ but only for very special cases. I recently wrote a major API in C with no debugger. My first experience with debuggers was in assembly language. We found that developers in the group were too dependent on the debugger. They were virtually building their programs in the debugger, producing horrible looking code. SignatureLee Fesperman, FFE Software, Inc. (http://www.firstsql.com) ============================================================== * The Ultimate DBMS is here! * FirstSQL/J Object/Relational DBMS (http://www.firstsql.com) >>> The issue is not cut and dry (IMO). My point is some >>> instructors think debuggers are a hinderance at the [quoted text clipped - 16 lines] > will be happy. When I did lots of C programming, > debuggers would save my life. I disagree with the emphasis on general understanding, unless that is an independent objective. Most of a large program will be completely irrelevant to any given bug. Why read 100,000 lines to find the 100 lines that matter? It's often much more efficient to first understand the bug, by collecting data about it. I don't see why the choice of language should affect the choice between inserted debug code and a debugger at all. They each have limitations. For example, printouts only show you the data you knew you wanted before the run started. That is not much of a handicap if the failure occurs in the first few minutes of a known test case. If you have to wait a few hours, or even days, for a failure a debugger's ability to view additional data based on what has been found, without rerunning, becomes invaluable. On the other hand, I can construct far more complicated filtering and decision making using inserted debug code than any debugger I've ever used would support. For example, you can ask what happened the last hundred times a line of code was executed, without producing output for the previous million executions. Of course, in most cases either works, and the choice is a matter of taste and what is most convenient. Patricia Patricia Shanahan coughed up: >>>> The issue is not cut and dry (IMO). My point is some >>>> instructors think debuggers are a hinderance at the [quoted text clipped - 30 lines] > For example, printouts only show you the data you knew you > wanted before the run started. In both the println() and debugger case, you see a variable, and then ask for it's value. A good debugger however will allow you to command: Stop the moment this variable is altered, and show me who does it. And println() will allow you to garner information in the manner you mention below, but also to garner information that might not exist at all in a debugging context, as I mention elsethread, regarding MT race conditions and the like. > That is not much of a > handicap if the failure occurs in the first few minutes of a > known test case. If you have to wait a few hours, or even > days, for a failure a debugger's ability to view additional > data based on what has been found, without rerunning, > becomes invaluable. Sure. > On the other hand, I can construct far more complicated > filtering and decision making using inserted debug code than [quoted text clipped - 4 lines] > > Of course, in most cases either works, most > and the choice is a > matter of taste and what is most convenient. ...for those of us who /know/ what we're doing. The question is in what order is it best to teach newcommers to the language, possibly newcommers to programming in general: 1. editor / javac / java 2. IDE OR 1. IDE 2. editor / javac / java (and therefore this argument has contorted to...) 1. println() 2. debugger OR 1. debugger 2. println() I think that both sides are starting to talk past each other. SignatureWith knowledge comes sorrow. > ....for those of us who /know/ what we're doing. The question is in what > order is it best to teach newcommers to the language, possibly newcommers to [quoted text clipped - 15 lines] > > I think that both sides are starting to talk past each other. For small student programs, the special cases that force use of one or the other are unlikely to happen, so it doesn't really matter. Good decision making about what to questions to ask, and persistence in tracking the bug to its root causes, are far more important than the details of what tools are used to capture the data. A functioning brain is the one essential debug tool. Everything else is accessories. Patricia > ...for those of us who /know/ what we're doing. The question is in what > order is it best to teach newcommers to the language, possibly newcommers [quoted text clipped - 4 lines] > 1. debugger > 2. println() Unfortunately my experience is that most graduates from school have only learnt the println() method of debugging - and never learn the debugger method because "it's too complicated". and the real tragedy is that we need some skill and practice at both methods. Stuart McGrigor The question is in what > order is it best to teach newcommers to the language, possibly newcommers to > programming in general: [quoted text clipped - 4 lines] > 1. IDE > 2. editor / javac / java And I would characterize it as the difference between 1. editor/javac/java/language OR 1. language 2. javac / java command line tools With the difference being that in the first case they will run into more problems trying to use the command line tools and won't necessarily actually learn how to use the tools as well. I don't list IDE because the goal is not to teach them an IDE. And I don't recommend just any IDE for a newbie. I love Eclipse and it is my favorite IDE, but I would never recommend it for a newbie. You want an IDE that takes care of the details for you and let's them focus on the language alone. I recommend BlueJ. There is almost nothing to learn with BlueJ. The entire tutorial on BlueJ is only 39 pages and has lots of pictures. SignatureDale King Bill Tschumy coughed up: ...[rip]... > The issue is not cut and dry (IMO). My point is some instructors > think debuggers are a hinderance at the early stages of learning to > program. IME there is a *lot* for a newbie to gain by learning debugging without a debugger. You get to learn clever ways around things, and how to subtly alter the code (even if only to add a println()) to have it tell you want is wrong. Signature"Well, ain't this place a geographical oddity! Two weeks from everywhere!" In article <%tSje.10979$mv5.8498@trndny07>, "Thomas G. Marshall" <tgm2tothe10thpower@replacetextwithnumber.hotmail.com> wrote: > Bill Tschumy coughed up: > [quoted text clipped - 8 lines] > alter the code (even if only to add a println()) to have it tell you want is > wrong. A lot of coders could gain enormous performance improvements if they took a look at what they were really executing rather than falling into a routine of writing the same garbage over and over again because they know it eventually produces the right answer. println() only tells you what you want to see, not what you need to see. Kevin McMurtrie coughed up: > In article <%tSje.10979$mv5.8498@trndny07>, > "Thomas G. Marshall" [quoted text clipped - 18 lines] > because they know it eventually produces the right answer. println() > only tells you what you want to see, not what you need to see. No, println tells you what you ask it to tell you, just like a debugger tells you what you ask it to tell you. SignatureSometimes life just sucks and then you live. > Kevin McMurtrie coughed up: > [quoted text clipped - 23 lines] > No, println tells you what you ask it to tell you, just like a debugger > tells you what you ask it to tell you. Well, no the debugger tells you more than you ask. The debugger of eclipse shows you all local and global variables. The println() - Statement shows you what you asked at all. But I havent found a debugger at BlueJ and the another starting IDE. To debug is very simple in a forward programm. If you use more than one Thread it getting more complex. A newbie will start to debug when he learned the language and switched the IDE. That is what my prof said to me when I asked him about debugging. He told me that not so many people debug as many people use println(). println() is the most used debug statement. Is that right? I like to debug more then to use println(). Timon Hinrichs coughed up: >> Kevin McMurtrie coughed up: >> [quoted text clipped - 28 lines] > eclipse shows you all local and global variables. The println() - > Statement shows you what you asked at all. That's far too simplistic. The debugger shows you whatever local and global variables you ask for. Same as the println. Even if the debugger were to show you everything all the time without you even having to press a single button, the mere fact that you are using the debugger is asking. We headed down this particular semantic argument because this utterance: Kevin McMurtrie: println() only tells you what you want to see, not what you need to see which IMO is wrong on so many levels. First of all, println() does /not/ tell you what you /want/ to see: it would tell you the values of something, which are things that you may or may not want to see or even expect to see. Secondly, it's the /process/ of learning how to use println() such that you get meaningful information. Third, a debugger hardly shows you what you "need to see" either, unless you also learn how to use it, just as you would learn to use println(). Println() debugging is not just a handy skill. It is often a /required/ skill. There are many times I've come across a MT race condition that "goes away" the moment a debugger is used. Furthermore, there exist also similar situations where the bug is latched to the current time (in real time) and therefore the problem is not reproducible once the code has been halted at a breakpoint. ...[rip]... SignatureWith knowledge comes sorrow. > Well, no the debugger tells you more than you ask. The debugger of > eclipse shows you all local and global variables. The println() - > Statement shows you what you asked at all. > > But I havent found a debugger at BlueJ and the another starting IDE. Then you didn't look very hard. BlueJ has a built-in debugger. Simply select Show Debugger in the View menu. To > debug is very simple in a forward programm. If you use more than one > Thread it getting more complex. [quoted text clipped - 4 lines] > println() is the most used debug statement. Is that right? I like to > debug more then to use println(). I'd say that often they solve different problems. There are things that really only can be debugged easily with a debugger and some that can only be solved with print statements. And unfortunately there are also problems where neither works. SignatureDale King >>>>The other crucial part that you leave out with your command line tools >>>>is a decent debugger, which is a valuable tool for a newbie to be able [quoted text clipped - 10 lines] > > So now anyone who disagrees with you is the equivalent of a "flat earther"? The was uncalled for. I'm simply saying that because someone says it doesn't mean its right. > The issue is not cut and dry (IMO). My point is some instructors think > debuggers are a hinderance at the early stages of learning to program. I can certainly agree that it can be misused. I've also seen the lack of debugging be a major hindrance on learning. The y often develop what I call superstitious coding and debugging. If something doesn't work right they will often assume that an API does not work correctly. >>A debugger is invaluable for letting a newbie see what is happening. You >>can teach polymorphism, but how much better to also show him that when I >>step into this method it actually goes to the subclass' method not the >>superclass, etc. > > It is also another thing to get in the way. What I was talking about there is using it as a teaching tool. Saying it gets in the way does not apply. What I describe is more like setting up an example, ask the students what this will do, and then you can actually step through it and see what it does. For kinestetic learners this is the best way to learn. SignatureDale King Dale King coughed up: >> Personally, I favor a simple text editor like JEdit and the command >> line [quoted text clipped - 6 lines] > understand what a class is. Everyone should learn the command line > tools, BUT not until you know the language. That IMO is entirely backwards. A new user of java absolutely /needs/ to "learn the ropes" of how to get the shipped compiler to work. For the most part they learn how to just get it going using a tutorial, and then they learn the ins and outs of /why/. They do not need to fully understand what a class is to get a classpath to work. Furthermore, learning how to control (not understand) a classpath is something they're going to need to understand sooner or later, so it might as well be something they are confronted with early on. Usually, when teaching a new language, I (or everyone else I know who has taught anything), starts off with how to get something akin to the hello world example to run. Even when I teach folks with an IDE, I go through the steps needed to configure, compile and run a HW app. And I /want/ them to use the editor, compiler, JVM, and documentation html separately, so that they can have a better chance at understand what goes on within an IDE. Geez Dale, what happened? All of your posts dropped out of the sky all at once. ...[rip]... SignaturePuzzle: You are given a deck of cards all face down except for 10 cards mixed in which are face up. If you are in a pitch black room, how do you divide the deck into two piles (may be uneven) that each contain the same number of face-up cards? Answer (rot13): Sebz naljurer va gur qrpx, qrny bhg gra pneqf naq syvc gurz bire. > Dale King coughed up: > [quoted text clipped - 13 lines] > A new user of java absolutely /needs/ to "learn the ropes" of how to get the > shipped compiler to work. Why? Why try to teach them something that they will not grasp and just gets in the way of learning the language. > For the most part they learn how to just get it > going using a tutorial, and then they learn the ins and outs of /why/. And in my experience they don't learn the why even later. They are given a formula for compiling and running without learning the why. When something goes wrong the have no way of figuring out how to fix it. They will get frustrated and often they will develop what I would call superstitions since they don't understand. In other words since they don't understand they will often come up with their own why that doesn't necessarily agree with reality. > They do not need to fully understand what a class is to get a classpath to > work. Furthermore, learning how to control (not understand) a classpath is > something they're going to need to understand sooner or later, so it might > as well be something they are confronted with early on. A agree they'll need to understand it, but I disagree with the sooner. They should learn the language to get the foundations for understanding it. > Usually, when teaching a new language, I (or everyone else I know who has > taught anything), starts off with how to get something akin to the hello > world example to run. Even when I teach folks with an IDE, I go through the > steps needed to configure, compile and run a HW app. The plethora of posts in these groups from helpless newbies trying to get hello world to run pretty much proves that your statements are wrong. And with something like BlueJ the the steps take about 30 seconds to explain. You want to compile hit the compile button, etc. > And I /want/ them to use the editor, compiler, JVM, and documentation html > separately, so that they can have a better chance at understand what goes on > within an IDE. Don't see how that gives them any advantage. > Geez Dale, what happened? All of your posts dropped out of the sky all at > once. I can only connect to my newsserver from home, so I download the groups and work offline and when I connect back up they all get sent. SignatureDale King Dale King coughed up: >> Dale King coughed up: >> [quoted text clipped - 16 lines] > Why? Why try to teach them something that they will not grasp and just > gets in the way of learning the language. It /doesn't/ get in the way! Learning the tools is important. >> For the most part they learn how to just get it >> going using a tutorial, and then they learn the ins and outs of [quoted text clipped - 5 lines] > They will get frustrated and often they will develop what I would call > superstitions since they don't understand. EXACTLY! Which is WHY they need to understand it and have it properly taught to them in the first place. Look, when a user gets a message that says something to the effect of "can't find HelloWorld.main()", it would be nice if he was at least half confident that his environment was correct! > In other words since they > don't understand they will often come up with their own why that [quoted text clipped - 18 lines] > get hello world to run pretty much proves that your statements are > wrong. Again, those statements say *nothing* to your argument, and don't prove anything one way or the other. By its very nature in usenet you are *not* seeing all the people who don't have a problem getting it to work. Posts like the following are rare: Subject: Hey guys, got HelloWorld working with no problem Body: That's all I wanted to say But they are (obviously) rare because people tend to post once they have issues, not if they don't! Signature"Well, ain't this place a geographical oddity! Two weeks from everywhere!" > Dale King coughed up: > [quoted text clipped - 20 lines] > > It /doesn't/ get in the way! If it doesn't get in the way then why do so many people post here unable to get HelloWorld to run. You keep saying that it doesn't make my point but it sure seems to be getting in the way of an awful lot of people. > Learning the tools is important. I have never said otherwise. To summarize my points: - Learning the tools is easier and the knowledge will be retained better if you learn the language first. - Learning the language is easier if you can use tools that concentrate on the language itself. >>>For the most part they learn how to just get it >>>going using a tutorial, and then they learn the ins and outs of [quoted text clipped - 8 lines] > EXACTLY! Which is WHY they need to understand it and have it properly > taught to them in the first place. No, they need to understand it and have it properly taught to them when they have been given the framework of knowledge to be able to understand it. > Look, when a user gets a message that says something to the effect of "can't > find HelloWorld.main()", it would be nice if he was at least half confident > that his environment was correct! And how in the world does a newbie know how to do that. We're talking about complete newbies here. Once again look at all the people who post here that have no clue on how to know if their environment is correct. >>>Usually, when teaching a new language, I (or everyone else I know >>>who has taught anything), starts off with how to get something akin >>>to the hello world example to run. Even when I teach folks with an >>>IDE, I go through the steps needed to configure, compile and run a >>>HW app. Here is a paper that claims that in a first course it is actually best to stay away from I/O in the beginning: <http://www.bluej.org/papers/1997-07-IO-considered.pdf> >>The plethora of posts in these groups from helpless newbies trying to >>get hello world to run pretty much proves that your statements are >>wrong. > > Again, those statements say *nothing* to your argument, and don't prove > anything one way or the other. It shows that people exist that have problems using the command line tools to run the simplest of programs which obviously hampers their ability to learn the language. And the opposite case for my point would not be those reporting no problems, but would be if there were a large number of people reporting problems getting simple programs to run in BlueJ. I don't recall ever seeing those. On a side note if BlueJ is used as recommended you would not start with HelloWorld as it introduces many concepts that you don't want to get into in the beginning. The signature for main itself includes static functions, void return type, and array parameters. It is recommended that you start with objects. That is easy with BlueJ and its ability to create and manipulate objects interactively. This is such a beneficial and useful tool for learning that even Micro$oft is copying BlueJ: <http://www.bluej.org/vs/vs-bj.html> SignatureDale King Dale King coughed up: >> Dale King coughed up: ...[rip]... >>> The plethora of posts in these groups from helpless newbies trying >>> to get hello world to run pretty much proves that your statements [quoted text clipped - 6 lines] > tools to run the simplest of programs which obviously hampers their > ability to learn the language. Well, we're at what's known as an impasse. Showing that there are people who have a problem doesn't show what percentage of people have a problem. It's just a meaningless statistic. Ah well. This is the point of usenet. Thanks for the discussion. SignatureUnix users who vehemently argue that the "ln" command has its arguments reversed do not understand much about the design of the utilities. "ln arg1 arg2" sets the arguments in the same order as "mv arg1 arg2". Existing file argument to non-existing argument. And in fact, mv itself is implemented as a link followed by an unlink. >> I have seen number of scenes where IDEs are nothing but serious >> stumbling blocks for Java programming beginners. I think that is [quoted text clipped - 16 lines] > > Steve What Steve said. George > I have seen number of scenes where IDEs are nothing but serious > stumbling blocks for Java programming beginners. I think that is [quoted text clipped - 8 lines] > What is your opinion about this? And, do we already have IDEs > for educational purposes? I designed Jurtle as an educational IDE. It is very simple to use and uses a built-in tutorial and Turtle Graphics (a.la. Logo) for teaching the basics of programming. Jurtle was designed for older middle school and high school students, but has been used by many adults that want a gentle introduction to programming. <http://www.otherwise.com/Jurtle.html> SignatureBill Tschumy Otherwise -- Austin, TX http://www.otherwise.com > I have seen number of scenes where IDEs are nothing but serious > stumbling blocks for Java programming beginners. I think that is [quoted text clipped - 8 lines] > What is your opinion about this? And, do we already have IDEs > for educational purposes? DrJava, the same people who do DrScheme and DrPython. Johnny > DrJava, the same people who do DrScheme and DrPython. I had some difficulty finding this, so to save anyone else the effort... http://drjava.org/ -- chris > > [quoted text clipped - 17 lines] > > What do you think are the nice features of DrJava? ------------------ BlueJ is the number one vote on this thread. But when I tried it, it did hang on a simple console program that does a lengthy System.out output. Not only did it hang, all of their windows became utter garbage on the screen. The program is normal when it is run from terminal java command. >>>I have seen number of scenes where IDEs are nothing but serious >>>stumbling blocks for Java programming beginners. I think that is [quoted text clipped - 21 lines] > Not only did it hang, all of their windows became utter garbage on the > screen. The program is normal when it is run from terminal java command. I normally use Eclipse and keep up on Netbeans and JDeveloper but I am a professional. Their is another beginner IDE called JGRASP. I would recommend you try that one. http://www.jgrasp.org/index.html jGRASP is a lightweight development environment, created specifically to provide automatic generation of software visualizations for the purpose of improving the comprehensibility of software. jGRASP is implemented in Java, and runs on all platforms with a Java Virtual Machine (Java version 1.3 or higher). jGRASP produces CSD diagrams for Java, C, C++, Objective-C, Ada, and VHDL; CPG diagrams for Java and Ada; UML diagrams for Java; and has an integrated debugger and workbench for Java. You can always use UltraEdit or TextPad to build and run your java programs. SignatureThanks in Advance... IchBin, Pocono Lake, Pa, USA __________________________________________________________________________ 'The meeting of two personalities is like the contact of two chemical substances: if there is any reaction, both are transformed.' - Carl Gustav Jung, (1875-1961), psychiatrist and psychologist > What do you think are the nice features of DrJava? It seems fairly nice, at least that's my impression based on playing with it for a few minutes. The integrated DynamicJava interpreter is a very welcome feature. The absence of masses of useless/irrelevant "features" is also welcome. I don't know how usable it would turn out to be in the long run; at first it seemed as if it might make a suitable environment for my own use (I dislike complication, and DrJava is pleasantly simple), but there are a couple of minor (mis)-features that make it unusable for me (it won't allow har |
Enable EMail Alerts
Start New Thread
Reply to this Message