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: Peter Duniho on 2 May 2010 12:21 Tom Anderson wrote: > [...] >>> but, we all know CRLF is the proper cross-platform line ending, since >>> after all, it is used by Windows... (and typically people develop on >>> Windows for Windows anyways, most non-Windows development often being >>> a misnomer...). even when it is for non-Windows deployment, it is >>> still typically developing on Windows for whatever is their target OS >>> / HW... > > I object strongly to this notion of a de facto Windows hegemony amongst > programmers. There is doubtless a majority, but it's not a monoculture. As a primarily-Windows programmer, I certainly agree with your point about line-endings. However, it's trivial to make that point without raising the question of programmer competence per-platform. >> 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. > > I used Windows for years, during the '95 and 2000 eras. From a > programming perspective, it was an improvement on the MacOS 9 which i'd > been using before that. But OS X and Linux are a *huge* improvement on > Windows. That's my experience. Does that count as religious fanaticism? Yes. My only Linux experience is via Java, but having done a fair amount of Mac programming both pre- and post-OS X, I can say with confidence that OS X is not a superior platform to Windows (this is true from both the user's perspective and the programmer's perspective), and that's not even counting the fact that the Visual Studio, and especially ..NET, development environment is _far_ preferable to me than Apple's Cocoa/Xcode/Interface Builder/etc. If you actually prefer the Apple platform and tools to, for example, Windows 7 and Visual Studio, more power to you. But to say that you can claim in an objective way that it's an "huge improvement" over Windows is absurd; such a statement can be made only from a religiously fanatical point of view. And to then extrapolate programmer competence from that view is just plain silly. Pete
From: Arne Vajhøj on 2 May 2010 13:41 On 01-05-2010 22:22, 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". That make more sense taken as English out of context. But given the context the last interpretation fits better. Arne
From: Arne Vajhøj on 2 May 2010 13:49 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. Arne
From: Lew on 2 May 2010 14:27 Arved Sandstrom wrote: > 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. "Correctly" according to you. I've heard "may not" to mean "might not" my entire life. "That may not turn out the way you expect." "There may not be enough for seconds." You may not be correct in your assessment of correctness, at least regarding common usage. > In any case, assuming that the spec writers were using English > correctly, they meant "has no permission to enforce". Since "may not" is ambiguous, they should not have used that phrasing. > 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". It may be the same thing. > 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. Your conclusion is correct. Not all your assumptions are. -- Lew
From: Lew on 2 May 2010 14:29
On 05/02/2010 01:41 PM, > On 01-05-2010 22:22, 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> Lew wrote: >> I read that as "might not enforce" as opposed to "has no permission to >> enforce". Arne Vajhøj wrote: > That make more sense taken as English out of context. It is just as ambiguous in context. > But given the context the last interpretation fits better. I disagree. I see only ambiguity. -- Lew |