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: Arne Vajhøj on 3 May 2010 22:03 On 03-05-2010 08:46, Tom Anderson wrote: > On Mon, 3 May 2010, Arved Sandstrom wrote: > >> Arne Vajh?j wrote: >>> On 02-05-2010 15:49, Arved Sandstrom wrote: >>>> Arne Vajh?j wrote: >>>>> On 02-05-2010 08:46, Arved Sandstrom wrote: >>>>>> Arne Vajh?j wrote: >>>>>>> On 01-05-2010 20:53, Arved Sandstrom wrote: >>>>>>>> What GUI tools? >>>>>>> >>>>>>> It seems to be the entire development suite. >>>>>> >>>>>> What it looks like, if we're examining Table 8-5 in that document, is >>>>>> that "Very High Level of Automation (circa 2000+)" gets a tool >>>>>> rating of >>>>>> 0.83 as compared to 0.91 for "High Level of Automation (circa >>>>>> 1980+)". >>>>>> >>>>>> So yes, approximately 10 percent better for 2000+. >>>>>> >>>>>> But look at what they are including for even 1980+: >>>>>> >>>>>> CASE tools >>>>>> Basic graphical design aids >>>>>> Word processor >>>>>> Implementation standards enforcer >>>>>> Static source code analyzer >>>>>> Program flow and test case analyzer >>>>>> Full program support library with configuration management (CM) aids >>>>>> Full integrated documentation system >>>>>> Automated requirement specification and analysis >>>>>> General purpose system simulators >>>>>> Extended design tools and graphics support >>>>>> Automated verification system >>>>>> Special purpose design support tools >>>>>> >>>>>> When was the last time you ever saw - let alone worked in - a shop >>>>>> that >>>>>> did even a substantial fraction of all of that? Particularly back >>>>>> in the >>>>>> '80s? It would have taken a very good operation indeed to be using >>>>>> most >>>>>> of those tools back in, say, 1985. Whereas if we examine the 2000+ >>>>>> list: >>>>>> >>>>>> Integrated application development environment >>>>>> Integrated project support >>>>>> Visual programming tools >>>>>> Automated code structuring >>>>>> Automated metric tools >>>>>> GUI development and testing tools >>>>>> Fourth Generation Languages (4GLs) >>>>>> Code generators >>>>>> Screen generators >>>>>> >>>>>> there is a much better chance, IMHO, that a larger fraction of >>>>>> that list >>>>>> is in play for even moderately good organizations. >>>>>> >>>>>> Worst case (and a fairly common one) we're really comparing text >>>>>> editor >>>>>> (1980+) to IDE (2000+). Good case (and also a reasonably common one) >>>>>> we're comparing most of the 2000+ list to very little of the 1980+ >>>>>> list. >>>>>> >>>>>> So I think in reality the productivity gains for most organizations, >>>>>> based on tools, have been considerably greater. >>>>> >>>>> I believe a lot of their input is DoD projects. They tend to >>>>> spend a lot on quality - the cost of launching a nuclear missile >>>>> due to a software bug is a bit high. >>>>> >>>>> The 10% sound very reasonable to me. >>>>> >>>>> If we just compare text editor to IDE and we assume that >>>>> an IDE is 10 times faster than a text editor and that >>>>> a developer on complex projects only spend 5% of the time >>>>> actually writing the code, then that part can only contribute >>>>> 4.5%. And 10 times faster is a rather aggressive assumption. >>>> >>>> Rightly or wrongly, with the state of software engineering being >>>> what it >>>> is I'd guess, based on observation, that many (if not most) developers >>>> spend more like 50 percent of their time - time which can be directly >>>> tracked against a software project - buried in their IDEs. Often it's >>>> higher than that. I've seen any number of junior and intermediate >>>> programmers over the years who are not tasked with anything but coding, >>>> in which case they are north of 75%. >>>> >>>> With those numbers then just a 2x speedup in using a IDE over a text >>>> editor is significant. >>> >>> Yes. >>> >>> But please don't use the term software ENGINEERING about a >>> process that spends 50-75% of the time in the IDE. >> >> I think it would depend on the role of the developer and the >> particular methodology in use - 50%+ time spent in the IDE might not >> be indicative of a low state of software process, or it might be. > > I find what i assume to be Arne's point shocking. The ideal software > process would spend *100%* of its time writing code, because it would > have optimised all the supporting activities to the point where all > working time could be put into the one activity that actually produces > the output. You think it is shocking that software engineers should spend more time thinking about the problems instead of typing full speed in their IDE? I think the definition of engineering is to think more than type. Arne
From: Arne Vajhøj on 3 May 2010 22:05 On 02-05-2010 22:49, Jim Janney wrote: > Arved Sandstrom<dcest61(a)hotmail.com> writes: > >> Lew wrote: >>> Arved Sandstrom wrote: >>>>> A lot depends on exactly what it is that people are writing. If I was >>>>> writing a Linux device driver in C I'd be cool with vim. But these days, >>>>> where I have to deal with .NET or J2EE web apps with thousands of source >>>>> files, I'd be an imbecile to try and do that with emacs. >>> >>> Arne Vajhøj wrote: >>>> Emacs is pretty close to an IDE. >>>> >>>> But I don't know how good its Java and C# support is though. >>> >>> For C and C++, given that emacs integrates source editing, >>> compilation, linking and debugging (synchronized with source >>> listings), "close" isn't accurate - emacs is an IDE. >>> >>> I have not found it as useful for Java. >>> >> I agree, for some languages like C or C++ emacs _is_ an IDE. A prof of >> mine wrote a fairly large C++ tool >> (http://gri.sourceforge.net/index.php) using emacs, and he would have >> been doing everything from within emacs. Depending on how much a >> person's emacs has been tooled up it's a mistake to call it a text >> editor. >> >> This is a fairly representative discussion regarding emacs vs Eclipse >> for Java: >> http://stackoverflow.com/questions/689544/is-emacs-useful-compared-to-eclipse-programming-java. >> >> >> I don't doubt that there are some very good Java developers out there >> who use nothing but emacs. If I used nothing but emacs, had it >> thoroughly tooled up, knew all my shell mantras and had shell scripts >> available to duplicate what a lot of Eclipse commands do, and had an >> encyclopedic knowledge of the Java APIs for the areas that I'm working >> in, I'd be just as fast as if I were using Eclipse. > > At one time I did a lot of coding in Emacs Lisp, using Emacs of > course, and for that Emacs was a very good IDE indeed, as good as > anything I've used. Which leads me to speculate that for reasonably > dynamic languages (Java and Lisp and C# but not C or C++) the best IDE > is one written in the target language. For example, I really expect > any Java IDE to take advantage of the reflection API, and that's > easiest done from Java (or at least some JVM-based language). I think that is more about eating ones own dog food paradigm. The technical problems of doing IDE for language A in language B are solvable. Some languages may not even be that suited for writing IDE's. I am not sure that writing a Fortran IDE in Fortran would be optimal. Arne
From: Arne Vajhøj on 3 May 2010 22:07 On 03-05-2010 07:37, Arved Sandstrom wrote: > Interestingly enough JDeveloper's parent, JBuilder (which I used back in > the day), is still available from Embarcadero (CodeGear). That's gotten > so far off my radar screen that I can't say I've run across anyone that > uses it in years. But surely some people do. AFAIK then newer JDeveloper versions does not have anything from JBuilder. Also note that the current JBuilder is Eclipse based. Arne
From: Lew on 3 May 2010 23:18 Arne Vajhøj wrote: > Well, if you agree that it can have that meaning and that meaning > makes more sense in the context and is similar to the meaning in > which it is used in other language definitions, then don't you think > it starts to indicate something? This has gotten way out of hand. Yes, the JLS meaning is as you say. That does not change the fact that it is not incorrect to use "may not" to mean "might not". I never disputed that the meaning of "may (not)" is ambiguous. /Au contraire/, that is the point I was making. I also was not defending the idea that it means "might not" in the JLS. All I said with respect to that is that I had always misread it that way before. It was the notion that it was incorrect to use "may not" to mean "might not" that I disputed. Apparently many people did not get that, yourself included. Buh-bye. -- Lew
From: BGB / cr88192 on 3 May 2010 23:52
"Martin Gregorie" <martin(a)address-in-sig.invalid> wrote in message news:hrmhv3$n7q$2(a)localhost.localdomain... > On Sun, 02 May 2010 19:36:53 -0700, BGB / cr88192 wrote: > >> OTOH, one can also use a different editor (I have little idea why MS >> never really bothered with LF-only line-ending support, as I wouldn't >> think this would be much more than maybe a few lines of code, but oh >> well, whatever...). >> > Most people who deal with this regularly have command line, and hence > scriptable, tools to deal with it, e.g. unix2dos and dos2unix in the UNIX > world or you can always use tr, which has been ported to about as many > OSen as grep has. > yes, this is one option for file conversion... just, I guess the mystery is why they never bothered with it in Notepad, given: they did deal with it in both WordPad and MS Edit; it is unlikely to be a major issue to add; they did go and add Unicode and UTF-8 support, which is presumably a much bigger issue to implement; .... but, granted, it doesn't really matter that much... |