From: Arne Vajhøj on
On 02-05-2010 14:29, Lew wrote:
> 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.

In the context of "If A then it may ... if B then it may not" is seems
obvious to me that may not should be interpreted as "under no
circumstances" because if "may not" actually means the same as "may",
then it could have been abbreviated to "It may ...".

Arne

From: BGB / cr88192 on

"Arne Vajh�j" <arne(a)vajhoej.dk> wrote in message
news:4bdcc97e$0$279$14726298(a)news.sunsite.dk...
> On 29-04-2010 05:18, Arved Sandstrom wrote:
>> 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.
>>
>> 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.
>
> Oh - the developer may not suffer, but all the people that has
> to do the final packaging, QA support and production support that
> the developer can not help with because the does not understand
> how the output of his development is used will suffer.
>

(irony / joke...):
simple: just send the IDE with the product and tell the end users the magic
ritual to invoke the program from the IDE...



From: Arne Vajhøj on
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.

Arne

From: BGB / cr88192 on

"Arne Vajh�j" <arne(a)vajhoej.dk> wrote in message
news:4bde2cf6$0$279$14726298(a)news.sunsite.dk...
> On 02-05-2010 19:28, BGB / cr88192 wrote:
>> the majority of those developers, in turn, either use MS tools (MSVC or
>> MS
>> Visual Studio), and very often, an MS technology (such as C# or VB.NET,
>> or
>> they may use J# as their preferred Java implementation).
>
> Practically no one has used J#.
>
> After all a Java 1.1 source code compatible language is not
> that cool a decade after the Java world moved on.
>

ok, fair enough...



From: BGB / cr88192 on

"Arne Vajh�j" <arne(a)vajhoej.dk> wrote in message
news:4bde26dc$0$283$14726298(a)news.sunsite.dk...
> On 02-05-2010 21:22, BGB / cr88192 wrote:
>> "Arne Vajh�j"<arne(a)vajhoej.dk> wrote in message
>> news:4bdcca13$0$279$14726298(a)news.sunsite.dk...
>>> On 30-04-2010 05:49, 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.
>>>
>>> Emacs is pretty close to an IDE.
>>>
>>> But I don't know how good its Java and C# support is though.
>>
>> personally, IMHO, I find that Emacs is just horrid and prefer to stay
>> well
>> clear of it...
>
> I am not particular happy with Emacs either.
>
> But just because it does not match my personal taste does not
> mean that it is not a good IDE.
>

fair enough, but I wasn't saying here that Emacs universally sucks, only
that in my opinion it is horrid and I prefer to stay clear of it...

I have used it before, but my personal impression was that the thing was
ugly and the keyboard shortcuts were generally absurd, and I much preferred
damn near any other editor, including vim, which I also don't particularly
like, except as the fallback that typically this is about the only editor
(apart from Emacs) which tends to come with typical text-only Linux
installs... (although some came with 'joe'...).

it is odd that about one of the (IMO) best pure text-mode editors was 'MS
Edit' for MS-DOS (which happened to handle about like Notepad, and the later
versions had ability to manage multiple open files, ...).

(although vim does have a hex editor, ...).

or such...