
Do modern IDEs make us dumber? - vorador
http://www.charlespetzold.com/etc/DoesVisualStudioRotTheMind.html
======
modoc
No. They (can) make us more productive.

When you're working with a large number of source files, the ability to have
auto-complete, parameter guessing, getter/setter creation, auto-builders, and
real-time code syntax/quality/checkstyle/pmd/findbugs/etc... validation means
you can write working code more quickly.

The ability to refactor/rename across an entire project with a click of a
mouse means I'm much more likely to refactor as the code evolves, leading to
higher quality, more readable, more extendable code. Seeing class hierarchy
trees with one click, jumping to view the source of a method I'm using, remote
debugging totally integrated with my source code, etc... is all really
valuable.

Sure, drag-and-dropping everything in some IDEs means you're missing a lot of
the core stuff in programming, but at least for me, I am more productive using
Eclipse than I was using Emacs and the shell.

~~~
sofal
There are both kinds of developers. I always thought Oliver Steele did a good
job of explaining this here:

<http://osteele.com/archives/2004/11/ides>

Here's my take:

The ability to write in a language that doesn't require excessive amounts of
boilerplate code means I'm much more likely to refactor as the code evolves.
Seeing an algorithm on one page, localizing and separating the logic cleanly
with higher level constructs, easily translating the intuitions in my head to
a coded solution, being able to dive into any part of the code without getting
lost in the redundancy and residue of IDE vomit, etc... is all really
valuable. Getters and setters that take up more than one very short annotation
are eyesores, and the mere act of coughing them up into the code was never a
bottleneck to programming speed no matter how bloated they get.

The act of automatically renaming classes or variables, along with all the
other code-shoveling refactoring support that IDEs provide is a miniscule
subset of what refactoring is really about. The real refactoring work is done
in your head. You need to look at the code and comprehend it in ways that
aren't obvious, so that you can reorganize it to be simpler or maybe
extendable. This kind of work cannot be done by an IDE; however, it can be
aided by using a nice expressive language that gets to the point and doesn't
distract you from the problem.

When it comes down to building, deploying, and automation of other menial
tasks, I'm not stuck with what the IDE developers give me. A good language is
like putty in my hands. An IDE locks me down and cumbers me, giving me little
in return other than a graphical debugger and quick syntax help. Once you have
mastered the command line, it becomes painfully obvious what the IDE cannot
do. An IDE is a static cockpit with lots of cool doodads and buttons. I can
make my own doodads and buttons and they will do exactly what I wish and they
will do it exactly how I wish.

I am a language maven.

~~~
azanar
>The real refactoring work is done in your head.

This has totally been my experience. Moving a method or variable up or down in
the inheritance tree, extracting part of a method, inlining method calls: all
of this is architectural refactoring. I've found the much of my refactoring
time isn't spent in moving methods around and modifying signatures; it is
spent in modifying the algorithms and data organization. Not organization in
the sense of whether variable belongs in sub- or super-class, but in the sense
of whether some subset of data should belong in a particular class, or some
new delegate class I construct. That new delegate class might not be a subset
of the class I'm splitting apart, so requires more than just some automated
extraction process. I can't help but create a mental picture of all of this as
a sort of architectural autopilot -- it can handle making minor course and
altitude corrections, but still expects you to have thought about things
before pressing the 'engage' button.

~~~
modoc
The guts of all application design and redesign (which is what refactoring
really is) is always done in your head. That's true no matter what tools you
use or don't.

------
dazzawazza
Good and bad programmrs use IDEs. Good and bad programmers use text editors.
Bad programmers use IDEs as a crutch, supporting their otherwise poor
programming skills.

It's simplistic to say that IDEs make us dumber. Auto-completion can lead to a
vagueness about code structure but refactoring tools can greatly aid
programmers to complete repetitive error prone tasks.

~~~
sofal
An IDE does a great job at helping you generate and manage repetitive code.
The problem is that it doesn't help you read and understand repetitive code.

The fact that a repetitive and error prone task needs to be done at all is
sometimes (not always, I acknowledge) a sign that your code is redundant and,
well, crappy. I think it's a good idea to step back and decide whether the
redundancy is legitimate. An IDE doesn't encourage that kind of thinking.
Remember, someone after you has to go and read that code, and the IDE is not
going to hide the redundancy from him or her. At the end of the day someone is
scratching their head and staring at a whole lot of text.

------
msg
I have grown to hate the MS family of programs's insistence that Daddy knows
best, and I must turn off the magic on a case-by-case basis.

I noticed a big difference when I transitioned from Visual Studio/Netbeans
type coding to Emacs. I stopped hunting through class hierarchies and started,
you know, actually learning the libraries I needed to use. Emacs lets me be
the magician.

I haven't programmed using XAML, but it reminds me of the .ui file produced by
Qt Designer, which I've edited by hand at times.

~~~
snprbob86
Hopefully, if the library designers are doing their jobs, you aren't hunting
through class hierarchies. Instead, you should be falling into a pit of
success.

That is, some path to your solution should always be immediately obvious and
that simplest path should always be the correct one. Clearly an unachievable
goal in the general sense, but surprisingly doable overall in statically typed
languages. One example: I know I have to call A.F(B), so I know that I need to
construct B, which offers B.ctor(X) and B.ctor(Y), but I don't have an X, so
clearly I need B.ctor(Y) ... etc. IntelliSense would have pointed you right to
it!

I used to have a tendency to thumb through IntelliSense (and sometimes I still
do!), but have taken to reading the docs before starting because most of the
libraries I interact with are just too complex! The real problem is, that the
majority of code that I consume isn't documented at all anyway, so hunting
through the class hierarchies (or code directly) is all I've got.

For the record, my tools are: C/C++ = Visual Studio and Source Insight; C# =
Visual Studio with Resharper; Java = IntelliJ IDEA; Python = Wing; Javascript
= _gggrrrrrrrr_ ; XML, HTML = Notepad2; Other text files = Notepad2 or Visual
Studio; whichever has the focus :-)

~~~
ajross
One might submit that if you were to learn a single editor and use it for all
your tasks, you might not only be more productive at each of them but your
answer to an editor for Javascript might be something other than "ggrrrrr".

~~~
snprbob86
I actually use Notepad2 for Javascript. It is a great, all around, bare bones,
dead simple editor. I say ggrrrrr because I want my IDE features!

I'm actually quite proficient at Vim. I used it day in and day out at Google
for 3 months. It just drove me nuts. Vim (and presumably Emacs) are fantastic
general-purpose text editors. Too bad I only spent a tiny portion of my time
editing general text. I spend the vast majority of my time editing CODE.

------
jacktasia
They don't make us dumber...they do make it a bit harder to become smarter
though, since they do so much for us.

------
sanj
I think that there's a forcing function with using a non-IDE environment that
makes me, at least, write better code. I have to navigate it and understand it
without (easily) jumping between files/methods/objects.

For me, that leads to better organized and better encapsulated code.

------
fuzzy-waffle
IDEs seem to be more a symptom of a programming environment that is poorly
designed especially if your IDE is generating large amount of code for you.
Perhaps that is what petzold was advocating if I could stand reading the talk
in its entirety.

------
lsb
I really love the DrScheme IDE. You can see the values that your functions are
passing each other, and I've prototyped some code using Scheme and it was a
really seamless experience.

------
michaelneale
Does watching TV make us dumber? Video games? Questions like this don't have
an answer but can be an interesting discussion.

I guess I consider emacs ad IDE (or at the very least toolkit to build a
personalised IDE). What about smalltalk? I don't think most would think of
that as "dumbing things down" yet it really invented all the good things that
IDEs have ?

------
hsuresh
Yes, if you are a beginner. I have seen many folks who start learning Java
with IDEs struggle with issues like classpath. So, at least as a beginner of
any new language, i would work with just a good editor (emacs/textmate)
instead of an IDE.

------
raamdev
As someone who started learning C a few months ago, it was comforting to hear
a 20+ year veteran programmer say that coding in C made him "feel like a real
programmer again".

------
axod
It'd be interesting to see a wide spread study on this. I've yet to meet a
good programmer that uses an IDE, but that could just be an anomaly.

------
hs
from my observations, OOP style programmer tends to rely most on IDE while FP
style the least

that might reflect the relative dumbness of the two

~~~
maxwell
Even so, I wouldn't want to write Lisp without at least paren matching.

~~~
hs
yes, i use vim and vi text editors for lisp paren matching is essential

it's not like i'm advocating writing code using cli or sed

------
known
IDE = Code re-use

------
bhiggins
Code generation is bad if you ever have to edit the code generated, under any
circumstances (the qualification excludes (good) compilers).

I like features like IntelliSense (when they work properly). I mean really, if
you don't like features like this then perhaps you should consider removing
auto-indent from your editor -- perhaps it's making you too lazy. As for me,
I'd rather not remember API minutiae if I can help it.

That's not to say I don't learn APIs. I do and it's important to understand a
system completely. But sometimes I forget the order of arguments to some
random function.

------
shard
Tl,dr. Anything interesting happen in this movie after Intellisense?

~~~
qqq
Mixed Metaphor!!

