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: Arved Sandstrom on 2 May 2010 08:46 Arne Vajh�j wrote: > On 01-05-2010 20:53, Arved Sandstrom wrote: >> Arne Vajh�j wrote: >>> USAF STSC publicized some research results for software costs last >>> summer. >>> >>> (quite an interesting paper I can recommend it) >>> >>> The concluded that the GUI tools from 2000 gave a >>> productivity increase of approx. 10% compared to >>> the text tools from 1980. >>> >>> At average the GUI tools are slightly more efficient. >> >> Can you provide a link for that paper? Thanks. They've got some good >> stuff but I never ran across that one. > > http://www.stsc.hill.af.mil/consulting/sw_estimation/SoftwareGuidebook.pdf Much obliged - looks like a good document. I am now reading the whole thing in detail. :-) >> Prior to me reading that research, my question is, what do they mean by >> productivity? > > They have some complex formulas. But it is a factor that is used > when going from KLOC/FP to man months. > >> 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'm convinced that that observation does >> not hold for what we are talking about. > > I would expect a modern IDE to be a good chunk of the development suite. > > Arne > AHS
From: Arved Sandstrom on 2 May 2010 09:23 Lew wrote: > John B. Matthews wrote: >>>> 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> >>>> > > Arne Vajhøj wrote: >>> This just say: >>> >>> <quote> >>> When packages are stored in a file system (§7.2.1), the host system >>> may choose to enforce the restriction that ... >>> </quote> >>> >>> But SUN's implementation (and probably all other common implementations) >>> of Java compiler does enforce. > > John B. Matthews wrote: >> Interesting. In contrast, "a system that uses a database to store >> packages may not enforce a maximum of one public class or interface >> per compilation unit." >> >> <http://java.sun.com/docs/books/jls/third_edition/html/packages.html#37739> >> > > I read that as "might not enforce" as opposed to "has no permission to > enforce". > The problem here is the use of modals like "may", which admit either epistemic (statement of inference/knowledge) or deontic (how things ought to be) interpretations. Fortunately "may not" is one of the modal negatives that has a fairly unambiguous meaning, as in, "not allowed". That doesn't mean that a lot of people don't use it incorrectly, though. In any case, assuming that the spec writers were using English correctly, they meant "has no permission to enforce". Because of the ambiguity of modals, especially "may" and "might", my opinion is that technical specifications should never use them. A lot of W3C specs have a terminology specification which defines "may" as referring to optional features, which is all well and good, but this provides no guidance for the meaning of "may not", which incidentally is not the same thing as "might not". The fact that we could (and do) spend significant time arguing over meaning when using some of these modals means, IMHO, that we shouldn't use them in specs. AHS
From: Arved Sandstrom on 2 May 2010 09:34 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. AHS
From: Eric Sosman on 2 May 2010 09:40 On 5/1/2010 8:38 PM, Tom Anderson wrote: > [...] > On any platform, you may find yourself confronted by files with any kind > of line ending at any time, which have arrived from via any route. > Declaring that all files must be converted on import is a complete > non-starter. Declaring that all programs must recognize (and perhaps generate) all the line-demarcation conventions of all systems everywhere is a Hell of a lot less practical. I have, personally, actually used systems that marked line boundaries - With a trailing LF - With a trailing CR - With a trailing CR LF pair - With a leading CR and a trailing LF - With a leading count and possibly a trailing pad - With a leading count plus other metadata and a possible pad - With no per-line data whatsoever I'm willing to wager a modest sum that you, personally, have *never* written a program that can deal with all of even this limited repertoire. Care to name an amount? -- Eric Sosman esosman(a)ieee-dot-org.invalid
From: Arved Sandstrom on 2 May 2010 10:46
Peter Duniho wrote: > Tom Anderson wrote: >> [...] >> I should have phrased it better: i don't know a single good developer >> who develops on Windows by choice. > > That says more about your own personal professional and social circles > than it does the real world. > > I happen to know a large number of good developers who develop on > Windows by choice. > > I also have observed a fair number of religious fanatics who have an > unwarranted anti-Windows bias, as if it's somehow an obviously-inferior > platform as compared to other mainstream ones. > > Pete Let me preface my comments with the statement that I think I am fairly OS-agnostic: I currently have 2 Dell desktops (my old dual-boot Windows XP Pro SP3 + Ubuntu 10.04 job, and my new Windows 7 box), and a MacBook Pro with OS X 10.6.3. Historically I've had other Windows computers, as well as Power Macs. At work I started out on UNIX and VAX/PDP. My first exposure to Linux was on work PCs, but much of the rest of the time we used Windows 3.1 (sometimes just to run Exceed :-)). Sometime later I'd have been using - at home - Windows 95/98, System 7.x, and PowerPC MkLinux pretty much on an equal basis. Currently on my MacBook I also run VirtualBox and Parallels for occasional forays into Solaris 10 and Windows XP at work. So personally I am not religious. I _have_ observed, however, that I either need one OS for certain kinds of work, or I'm more productive on a certain OS for certain kinds of work. So at any given time I'll have projects on either Mac OS X, or on Windows, or on Linux. And Java projects can be found on all 3. Having said that, I don't believe that _anyone_ is on any of Windows or Linux or Mac OS X (or other OS's for that matter) *by choice* unless they have extensively used all of them. Restricting the discussion to Java (which I hope we are all doing) I know a lot of developers, many of them good developers, who develop exclusively on Windows. The majority of developers I know use Windows. But almost all of them have never really used anything else but. So are they using Windows "by choice", or just because it's what they know best? My money's on the latter. I don't think any developer will be shortchanged by using Windows, though, even if they didn't really "choose" it. You may end up throwing cygwin on there (I've noticed a fair few Windows-only folks do that), but that's not a bad thing. The servers and IDEs run just as well on Windows as they do on Mac OS X or Linux. And you can do a hell of a lot more on a Windows command line than even many Windows developers are aware of...don't even get me started on PowerShell which I've never actually seen anyone else except me use. AHS |