Do you suggest me using IDE when I'm learning JAVA
in [Java Help]
|
Prev: call jni function dynamically without getting a JNIEnv handleas an argument.
Next: Encoding issue on my jsp page
From: Eric Sosman on 2 May 2010 15:18 On 5/2/2010 2:27 PM, Lew wrote: > 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. "Mom, can I use the car?" "You mean `may'." "Sorry. Mom, may I use the car?" "No, you may not." -- Eric Sosman esosman(a)ieee-dot-org.invalid
From: Arved Sandstrom on 2 May 2010 15:41 Lew wrote: > 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. I think I'm correct. :-) I pointed out "That doesn't mean that a lot of people don't use it incorrectly, though." In fact I'd say that the majority of people use it incorrectly, which is why you've heard incorrect usages all your life. >> 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. That's the main take-away point. It would be so simple for the spec writers just to say "are not allowed to", which is pretty hard to misinterpret. AHS
From: Arved Sandstrom on 2 May 2010 15:49 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. > > Arne 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. AHS
From: Lew on 2 May 2010 16:11 On 05/02/2010 03:18 PM, Eric Sosman wrote: > On 5/2/2010 2:27 PM, Lew wrote: >> 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. > > "Mom, can I use the car?" > > "You mean `may'." > > "Sorry. Mom, may I use the car?" > > "No, you may not." Your point may not have been clear here. What are you trying to say? -- Lew
From: Lew on 2 May 2010 16:24
On 05/02/2010 03:41 PM, 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. Lew wrote: >> "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. Arved Sandstrom wrote: > I think I'm correct. :-) I pointed out "That doesn't mean that a lot of > people don't use it incorrectly, though." In fact I'd say that the > majority of people use it incorrectly, which is why you've heard > incorrect usages all your life. It is your terminology "correct" vs. "incorrect" that is incorrect. The dictionary definition of "may" includes the notion of "possibility" or of "permission" depending on context. Either usage is "correct". The same holds for the negation. Some people, according to the dictionary, consider the affirmative definition to mean "might" as incorrect, but that is a prescriptive restriction not commonly followed. Now if by "correct" you mean "unambiguous", I agree with you, but as for it being incorrect English usage to use "may" or "may not" in the sense of "might" or "might not", you're just plain wrong. <http://en.wikipedia.org/wiki/Wikipedia:Ten_things_you_may_not_know_about_Wikipedia> <http://www.usatoday.com/tech/news/2010-04-21-braingames21_ST_N.htm> <http://www.nytimes.com/2010/04/18/business/18digi.html> and perhaps most tellingly, <http://www.admin.ox.ac.uk/proctors/info/pam/section9.shtml> "... late entries may not necessarily be accepted." I think we can probably take Oxford University's usage as "correct". -- Lew |