Do you suggest me using IDE when I'm learning JAVA
in [Java Programming]
|
Prev: call jni function dynamically without getting a JNIEnv handleas an argument.
Next: Telnetting to diff IP with same port number
From: BGB / cr88192 on 1 May 2010 12:28 "John B. Matthews" <nospam(a)nospam.invalid> wrote in message news:nospam-45A640.10254701052010(a)news.aioe.org... > In article <hrghdl$35u$1(a)news.albasani.net>, > "BGB / cr88192" <cr88192(a)hotmail.com> wrote: > >> Java imposes the one-class-per-file restriction > > More specifically, one public, top-level class per file. There can be an > arbitrary number of package-private and nested classes. > > <http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.6> > <http://java.sun.com/docs/books/tutorial/java/javaOO/accesscontrol.html> > <http://java.sun.com/docs/books/tutorial/java/javaOO/nested.html> > granted, but I meant excluding these and similar... either way, it is not the free-form "collection of loosely-related stuff" strategy one can typically use with C and C++, where one is more free to organize file contents generally however they want... granted, with C++ many people still follow a one-class-per-file organization as well (or, more like, one class per pair of header-and-source file).
From: Mike Schilling on 1 May 2010 12:29 Lew wrote: > > A developer who can churn out effective and useful code (KLOC being a > useless measure of productivity) with an IDE and a low error rate > will naturally be much faster (and more effective) than someone who > fudges away with a text editor, getting caught up on details like > what exactly encapsulating a field is, or has troubles due to the > creation of several different objects with conflicting names. Or simply making typos that the IDE catches immediately, rather than having to fix them during some number of compilation cycles.
From: BGB / cr88192 on 1 May 2010 12:48 "Lew" <noone(a)lewscanon.com> wrote in message news:hrhe8g$grh$1(a)news.albasani.net... > BGB / cr88192 wrote: >> I think a lot of this would depend on various factors: >> the speed and skills of the developers involved; >> the particular languages and coding practices in use; >> ... >> >> for example, a developer who can (on a good day) churn out several >> kloc/day with Notepad and with a relatively low error rate, will >> naturally still be much faster than someone who fudges away getting >> caught up on details like what exactly "Encapsulate Field" does, or >> starts having troubles due to having created several different objects >> with conflicting names... > > In other words, a developer who understands programming and knows what > they're doing will outperform a developer who doesn't. > > I don't think the IDE is a factor in that. > > A developer who can churn out effective and useful code (KLOC being a > useless measure of productivity) with an IDE and a low error rate will > naturally be much faster (and more effective) than someone who fudges away > with a text editor, getting caught up on details like what exactly > encapsulating a field is, or has troubles due to the creation of several > different objects with conflicting names. > well, the IDE is a factor, mostly since it is often portrayed as being a sort of productivity silver-bullet... someone who doesn't know what their doing, even with such a silver-bullet, will not outperform someone who does know what they are doing, regardless of particular tool choice. now, if both people are otherwise fairly equal skill-wise, then it is more of a contest, and I suspect which is faster is likely to depend a whole lot on the particular task and coding practices in use, ... for example, in the creation of GUI apps (and IDE's with support for this built-in), then the person with the IDE will be at a notable advantage. if they are doing something like kernel development or compiler writing, then the IDE is not likely to provide as much help. > (One period suffices to end a sentence.) > how many periods is best I think depends on the particular semantics and affect of the sentence being ended. a single period has the idea of finality, namely that the particular sentence or idea has ended. "..." has the sense that the idea goes on, but the writer is not going to spend lots of time going over the various possibilities, describing each one, ... I guess it can also be used to indicate when a person is drifting from one topic to another, and the things separated by elipses are not necessarily related, for example: "and then I was doing some homework... oh look, a dog has wandered by the window... and the homework was being really boring and difficult... the dog turns in a circle and sniffs himself... the birds are singing in a tree." (absent elipses this chain of thought would seem to be broken). http://en.wikipedia.org/wiki/Elipses or such...
From: BGB / cr88192 on 1 May 2010 13:10 "Arved Sandstrom" <dcest61(a)hotmail.com> wrote in message news:L9cCn.2790$z%6.1619(a)edtnps83... > Arne Vajh�j wrote: >> On 28-04-2010 20:12, Arved Sandstrom wrote: >>> Up until not so long ago I recommended making use of a text editor for >>> initial basic learning. Now that I've really thought it though, I see no >>> point in using anything but a good IDE. An IDE provides assistance in >>> entering code, and there's nothing wrong with that. >> >> There is nothing wrong with the code typing assistance. >> >> But IDE from day 1 often result in people that do not know >> anything about how to run things outside the IDE. >> >> Arne > > That's entirely possible, that some people will have barely any grasp of > how to work outside the IDE. If we discount developers leaving the IDE fro > time to time to use a word processor or web browser, and also include the > ability of the IDE to call up server consoles and what not, then these > days with the latest IDEs a person can likely get away with using the IDE > for everything and not suffer. > and then experience vendor lock-in and the inability to "port" their code to another OS (or IDE...). one could easily see such a person trying to, say, copy-paste piles of code (from the editor windows, or worse-yet, from the GUI designer) between, say, Visual Studio and Eclipse, and not really have any idea why all their stuff is blowing up in their face, or end up bewildered at the thought of how to make use of 3rd party libraries, ... so, there is some merit in a developer having some understanding of what is going on underneath. it is much like how there is merit in end users having some idea how the filesystem works, and so not being hopelessly confused with the idea of how to send contents from "My Documents" to a different computer.
From: Arved Sandstrom on 1 May 2010 15:48
BGB / cr88192 wrote: > "Arved Sandstrom" <dcest61(a)hotmail.com> wrote in message > news:L9cCn.2790$z%6.1619(a)edtnps83... >> Arne Vajh�j wrote: >>> On 28-04-2010 20:12, Arved Sandstrom wrote: >>>> Up until not so long ago I recommended making use of a text editor for >>>> initial basic learning. Now that I've really thought it though, I see no >>>> point in using anything but a good IDE. An IDE provides assistance in >>>> entering code, and there's nothing wrong with that. >>> There is nothing wrong with the code typing assistance. >>> >>> But IDE from day 1 often result in people that do not know >>> anything about how to run things outside the IDE. >>> >>> Arne >> That's entirely possible, that some people will have barely any grasp of >> how to work outside the IDE. If we discount developers leaving the IDE fro >> time to time to use a word processor or web browser, and also include the >> ability of the IDE to call up server consoles and what not, then these >> days with the latest IDEs a person can likely get away with using the IDE >> for everything and not suffer. >> > > and then experience vendor lock-in and the inability to "port" their code to > another OS (or IDE...). Only if they don't understand where all the artifacts are. Which both of us comment on further below. > one could easily see such a person trying to, say, copy-paste piles of code > (from the editor windows, or worse-yet, from the GUI designer) between, say, > Visual Studio and Eclipse, and not really have any idea why all their stuff > is blowing up in their face, or end up bewildered at the thought of how to > make use of 3rd party libraries, ... > > so, there is some merit in a developer having some understanding of what is > going on underneath. > > it is much like how there is merit in end users having some idea how the > filesystem works, and so not being hopelessly confused with the idea of how > to send contents from "My Documents" to a different computer. You won't find me arguing that an IDE user shouldn't understand all source artifacts generated by the IDE. In my experience when using the various Java IDEs, or Visual Studio, or somewhat more esoteric IDEs like Anjuta or Leksah, you can always find the "raw stuff" so that you can, if necessary, dispense with the IDE and proceed with text editor and command line tools. Also in my experience, developers that are going to amount to anything do find out what the sources - Java, C#, F#, HTML/XHTML, XML etc - are, and how to edit them directly. And in any case a developer using an IDE may, depending on inclination, be looking at the unvarnished source just as if they were using a text editor like vi, except that the IDE also understands that source but vi doesn't. The only thing I have no patience with is if a developer lets an IDE shortcoming or defect stall them in getting work done, when there is *always* a way of bypassing the IDE. I've seen people get stuck with flaky server adapters in Eclipse, or buggy ESB/BPEL configuration wizards in JDeveloper, or have EAR deployment issues to J2EE servers, when all they had to do was work outside the IDE for these things. AHS |