From: Tom Anderson on
On Fri, 30 Apr 2010, Arved Sandstrom wrote:

> I also happen to believe that a lot of these folks who praise text
> editors to the skies, and who think that great hackers don't use IDEs,
> are making a virtue out of artificial and unnecessary self-imposed
> constraints.

It's also a complete lie. What did Alan Kay use while developing
Smalltalk? Naturally, he used Smalltalk, which is effectively an IDE.

tom

--
I DO IT WRONG!!!
From: Arne Vajhøj on
On 01-05-2010 12:48, BGB / cr88192 wrote:
> "Lew"<noone(a)lewscanon.com> wrote in message
> news:hrhe8g$grh$1(a)news.albasani.net...
>> BGB / cr88192 wrote:
>>> I think a lot of this would depend on various factors:
>>> the speed and skills of the developers involved;
>>> the particular languages and coding practices in use;
>>> ...
>>>
>>> for example, a developer who can (on a good day) churn out several
>>> kloc/day with Notepad and with a relatively low error rate, will
>>> naturally still be much faster than someone who fudges away getting
>>> caught up on details like what exactly "Encapsulate Field" does, or
>>> starts having troubles due to having created several different objects
>>> with conflicting names...
>>
>> In other words, a developer who understands programming and knows what
>> they're doing will outperform a developer who doesn't.
>>
>> I don't think the IDE is a factor in that.
>>
>> A developer who can churn out effective and useful code (KLOC being a
>> useless measure of productivity) with an IDE and a low error rate will
>> naturally be much faster (and more effective) than someone who fudges away
>> with a text editor, getting caught up on details like what exactly
>> encapsulating a field is, or has troubles due to the creation of several
>> different objects with conflicting names.
>
> well, the IDE is a factor, mostly since it is often portrayed as being a
> sort of productivity silver-bullet...
>
> someone who doesn't know what their doing, even with such a silver-bullet,
> will not outperform someone who does know what they are doing, regardless of
> particular tool choice.
>
> now, if both people are otherwise fairly equal skill-wise, then it is more
> of a contest, and I suspect which is faster is likely to depend a whole lot
> on the particular task and coding practices in use, ...
>
> for example, in the creation of GUI apps (and IDE's with support for this
> built-in), then the person with the IDE will be at a notable advantage.
>
> if they are doing something like kernel development or compiler writing,
> then the IDE is not likely to provide as much help.

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.

Arne


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

Arne
From: Tom Anderson on
On Sat, 1 May 2010, Arne Vajh?j wrote:

> On 28-04-2010 08:43, Tom Anderson wrote:
>> On Tue, 27 Apr 2010, Arne Vajh?j wrote:
>>
>>> On 27-04-2010 14:55, Lew wrote:
>>>> cr88192 wrote:
>>>>> anymore, I typically just do coding (in general) via the mix of
>>>>> Notepad,
>>>>
>>>> Notepad is very bad for Java programming because most extant versions
>>>> don't handle Unicode and they don't like cross-platform line endings.
>>>
>>> Notepad has supported Unicode since at least Windows XP from 2002.
>>>
>>> There are no such a thing as cross-platform line endings.
>>>
>>> It is true that notepad only supports the Windows CR LF, which
>>> means that it does not work when text files are moved as binary
>>> files from *nix.
>>>
>>> But instead of blaming notepad then people should transfer the
>>> files correctly.
>>
>> Rubbish. Should they unpack every jar they move across and see if it has
>> text files in, so they can convert them? Should they then have to
>> magically re-sign any sealed packages whose contents have changed?
>
> Given that notepad does not support editing of text files inside jar
> files, then there are absolutely no point in that nor any relevance for
> the discussion.

What? Where does the idea of editing files inside JAR files come into
this?

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.

tom

--
I DO IT WRONG!!!
From: Arne Vajhøj on
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.

Arne