[antlr-interest] are ides a good thing? (was: Serious doubts on usage of incrementalparsinginides)

[Eduard Ralph]

Hi,

this is probably a bit off-topic, but here I go anyway.

> Are ides even a good thing? :-)

I would say yes.

> And, I think it was IBM's work, it has been shown that code that is
> written and checked WITHOUT the aid of a computer tends to work better
> than code that has been written interactively. 

I'm a bit sceptical about that sort of thing. What were the criteria for
good?

> I *much* prefer working
> on paper - it's far easier to have an overview over the entire project -
> and all these fancy tools get in the way.

Depends on what I'm trying to do. I'll agree that conceptualizing certain
things like my UML Diagrams work better for me doing it by hand, but when it
comes to actual coding I wouldn't want to miss my tools. Plus which, you end
up having to code the stuff from paper into the machine again anyway.

> It's my guess that people who do make this transition are far less
> reliant on visuals or, like me, actually tend to positively *dislike*
> visuals. 

I would be very careful on that tenant. I think you are equating visuals
with imagination. It is correct that often one needs to be able to draw on
ones imagination to make an abstraction - making the connection to
non-visual is a far more dangerous assumption to hold. Disliking tools could
easily be interpreted as inflexibility to adaptation and actually resisting
future trends. Following your argumentation I would have to disavow the
mouse and the GUI for a command line. Some of you might agree that the GUI
was the worst thing to do (I knew one Professor who would turn the mouse
over on its back as first action at a computer), but by in large it helps me
and just about anybody else I know get things done quicker more effective.

> It's my belief (and experience) that ides make life easier for
> the average guy, but that the *good* programmer does even better without
> one.

One I'm not willing to share with you. What I would agree on, is that all
the bells and whistles do not replace the most important feature in every
project: the developers brain. If you are willing to let your tools to take
over everything, then obviously the quality of the solution will be poor. So
sitting down and thinking about what you're doing is sometimes more
important then just hacking away.

> But something (such as VS) that actively forces me to think in
> "nuts and bolts" mode all the time is an active hindrance - and it does
> it in the name of making me more productive!

I have never experience VS to be that way. Nor emacs or any other software
tool I ever used. The fact is: you need to know the tool you're working
with. And that requires time. Nobody would expect a carpenter to be able to
use a totally new-fangled saw off the bat. It takes time and experience. And
every tool as complex as emacs or VS require time.
That of course leads to a more principle question: why are our user
interfaces so poor, that I have such a learning curve involved with learning
a tool like VS or emacs? But that is of course a horse of a different color.

Greets,

Eduard Ralph