[article] Does Visual Studio Rot the Mind?

  • Thread starter Thread starter Will Chamberlain
  • Start date Start date
W

Will Chamberlain

I came across a rather interesting article this morning and thought I'd
share. We all know that Visual Studio is a great IDE, but I think we can
all agree that it is adds a dramatic change to how we write code.

I'm not posting to talk trash or start a flamewar, just wanting feedback
in regards to the following article. I happen to use Visual Studio on a
daily basis and am not a John Rivers alter-ego.

http://charlespetzold.com/etc/DoesVisualStudioRotTheMind.html

- Will
 
Excellent perspective presented in the article - thanks for posting it.

It triggered the thought that when you solve one problem you're likely
creating others (i.e., there's no free lunch). So, rather than blindly
adopting something or rejecting it (.NET in general, Visual Studio itself,
Intellisense, project templates, what-have-you.), some conscious
decision-making is prudent. Petzold gives those of us who maintain high
standards plenty of "food for thought." Of course conscious and proactive
decision-making is something that is done only by those who CARE about
maintaining high standards. Those of us with such values are likely already
not blindly accepting everything that Visual Studio does for us. The article
will be interesting to those with high standards, although it likely won't
cause us to do anything very differently. On the other hand, the article
ultimately will not be read by the people who would arguably benefit most
from understanding the points made (i.e., those with low standards). Even if
a few of them read it, they won't CARE about any of the points. They would
likely rate the article low because it doesn't give them a quick tip
(complete with sample code, of course) on how to do something at work the
next day.

-GH
 
Hello, Guadala.

I try not to get involved in "philosophical" arguments here but,
although I agree that there's a lot of food for thought in Petzold's
talk transcription, I don't see the relationship of the content to
either "high standards" or "low standards".

I absolutely agree with you that "when you solve one problem
you're likely creating others (i.e., there's no free lunch)" but Petzold,
when he refers to Intellisense, for example, says that :

"Of course, I could always just turn it off.
And go cold turkey? I don’t think so!"

"IntelliSense is a technology that is inevitable. If Microsoft hadn’t done it,
somebody else would have. Human beings have never been inclined to
refrain from pursuing certain technologies because they may have
unfortunate repercussions."

And...do notice that he doesn't turn off Intellisense... ;-)

The "unfortunate repercussions" Petzold mentions are mainly that programmers
"don’t need to remember anything any more. IntelliSense will remember it for me."

Well, duh! We might as well outlaw dictionaries.

If we didn't have dictionaries available, we'd all be on our way to having
super-endowed brains instead of having to look up the meaning of words
in tools like dictionaries, which will make our brain rot because they
make it easier for us to know what a sequence of phonemes, that we
have never seen before, stand for.

The same for Intellisense.

If we only would memorize 60,000 class definitions, methods and properties,
we wouldn't need to have Intellisense as a tool.

I think this all goes back to the "real programmers use vi" syndrome.

Having tools doesn't bother me, and I don't worry that
-by using them- my brain is going to turn to jelly. It won't.

If we extended that argument, cars would make our legs rot,
and using knives would make our fingers weaker.

We just don't work that way.

Petzold makes a lot of good points in his talk.
Reducing them to "high standards" vs. "low standards" does him a disservice.




Juan T. Llibre, ASP.NET MVP
ASP.NET FAQ : http://asp.net.do/faq/
Foros de ASP.NET en Español : http://asp.net.do/foros/
======================================
 
I'm a bit disappointed with Charles regarding this article. It seems he may
be suffering from a slight case of Future Shock. For anyone who has not
heard that term before, Google "Alvin Toffler" and/or "Future Shock."

I am nearly 50 years old. However, I still prefer to remain on the cutting
edge of technology, "riding the curl" as it were. I only have a limited time
on this planet. I'd like to see as much as possible during my tenure.

In this case, I believe Charles' analysis of Microsoft's software philosophy
and architecture is bass-ackwards. That is, Microsoft is the most successful
software company in the world, employing some of the brightest minds of our
generation to create the most successful software in the world. To begin
with the assumption that, because one has difficulty adapting to it,
therefore Microsoft may be at fault, is to begin with a faulty assumption.

When I analyse new software technologies developed by Microsoft, my initial
approach is, what can I learn from the masters? In other words, by looking
at the result, I can derive the line of logical thought process that led to
the design of the software that we are looking at. Of course, this is not
possible in a vacuum. I do not study Microsoft alone. I try to keep current
with the latest products of various standards organizations like the W3C,
ISO, and ECMA at the same time, to put things into their proper context. In
addition, I keep my peripheral eye on the most successful of Microsoft's
competition, to see how it all fits together. This provides what I consider
to be a useful context for my analysis.

The design of software is predicated upon a set of requirements. Of course,
we cannot know all of the requirements that contribute to the design of
Microsoft software, but we may certainly be able to derive some of them from
the final product, and the context in which it is created, with some degree
of accuracy.

Charles complains that Visual Studio does not readily afford the developer a
great deal of freedom with the way that code is organized, and that claim is
certainly true, exactly as I have stated it. First, Visual Studio tends to
coerce the developer to a certain set of "best practices" that Microsoft has
developed. Second, while it is certainly possible to configure Visual Studio
to a different methodology, it requires a certain level of expertise and/or
research in order to do so. While Charles questions this, I feel that he has
missed an important step in his analysis: Understanding the logic behind it.
Let me elaborate.

Charles is a couple of years older than I. He ought to be able to remember
the "frontier days" of X86 programming, using DOS, command-line compilers,
various flavors of Kernigan&Ritchey C, and having to write software that
provided its own peripheral drivers, etc. I can certainly remember using a
variety of software packages for different types of things like Word
Processing, Database access, etc. One of the things I fondly recall (only
fondly because I no longer have to put up with it) is having a number of
cardboard "Cheat Sheets" with the various shortcut keys of the various
software packages, laid out or taped somewhere near the computer, since the
Mouse was not yet invented, and every software manufacturer had their own
set of proprietary shortcut keys for their software. This was
anti-productivity.

Competition relies heavily on productivity. Henry Ford was successful
because of his assembly line. The assembly line was a concept that created a
set of standards, a standard process for creating cars, with a number of
positions at which certain types of operations were performed in exactly the
same way repeatedly during the manufacture process. This made the Ford
company more productive. They were able to sell their cars for less money
because it cost them less money to build them.

Microsoft has always made productivity the central pillar of their software
development philosophy. Software which promotes productivity will sell
better than software which does not, because productivity increases the
ability to compete. Productivity is almost always centered around the
establishment of a set of more or less arbitrary standardized methods for
performing certain tasks, and, in the area of computing, automating those
tasks as much as possible, which frees the user to take on the more
difficult tasks that require creativity and intelligence.

Personally, I am only enjoying myself when I am employing creativity and
intelligence. Therefore, where I declare variables in my code, what rules of
capitalization I employ, whether my IDE promotes a top-down or a bottom-up
approach to organizing my code, none of these things interest me. What DOES
interest me is creating software that does way-cool stuff, makes my ideas
into reality, and enables me to crank out the software I design quickly, so
that I can go back to the drawing board and dream up the next way-cool
software.

Software development has become complex, requiring teams of developers to
create. Productivity demands that these developers adhere to a set of more
or less arbitrary standards, in order to interact more smoothly. What
Microsoft has done is to make these arbitrary decisions *by default* and
allow the developers more time to do what they do best: make software
happen.

Now, as to the reason why these things are not readily changeable: There are
many levels of software developers in the world. A combination of the
advanced tool sets available, demand for software developers, and pure lazy
human nature has created a segment of the software development community
that has very little ability to think and reason for themselves. I have come
to accept this, begrudgingly. There is actually a use for these "useless"
people in the world. However, if left to their own devices, they would
become a support nightmare for companies like Microsoft. They know just
enough to get themselves into a great deal of trouble if allowed to do so.

Therefore, while Visual Studio is incredibly configurable, much of that
configurability is hidden from the easy-access level, and documented in
hard-to-reach places, in much the same manner as child-proof caps on
medicine bottles. If one can find them, and use them, one has a certain
necessary skill level to do so.

So, what makes Charles Petzold, who admittedly writes some very good
instructional books about programming technologies, get his attitude from?
My theory is that his vocation dictates it. Charles has a very specific use
for software like Visual Studio, and other programming tools. He writes
about things like the C# language. In order for him to do so, he admittedly
tells readers to start with an empty project, and type their code in by
hand. This is an excellent idea for teaching people how to program, how
languages and programming technologies work. Charles is teaching in the way
that any good teacher does. He does not want the budding developer to simply
let the IDE write his software for him, without understanding the whys and
wherefores of that code. I applaud that. I have seen far too many developers
of the sort that Charles wants to prevent. That is what makes Charles a good
author and teacher.

But there is a difference between learning how to program, and programming
for a living. And there is a difference between using software to teach
programming, and using it to write programs. Charles works in a
highly-specialized realm. He is not, at this point, a programmer, but a
teacher. And Visual Studio.Net, and other software development tools
manufactured by Microsoft, are created with the professional developer in
mind.

I am only disappointed that Charles doesn't seem to realize this.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.
 
I saw the thread on /. blah blah blah he's more than welcome to use
notepad as far as i'm concerned.

karl
 
Well said.

I think a lot of us never really notice the things he complains about
because we've made the sort of non-trivial customizations that you
speak of to get rid of them. In my case, I've all but forgotten the
nightmare of trying to set up a new Web Project because I use .dll
projects for everything I do, web or otherwise. All the templates for
the various file types are now ones I have written myself to suit my
style and placed in that magic directory far beneath the VS.NET
install. All the shortcomings of Intellisense that the author mentions
are long gone because I have ReSharper installed and configured the way
I like (so I haven't typed a Using directive by hand in two years!)

But yeah, I don't think I'll be going back to notepad any time soon.



Jason Kester
Expat Software Consulting Services
http://www.expatsoftware.com/
 
Hi Juan,

I totally agree with all of your points. I too love MS, Intellisense, and
all the help I can get in order to be more productive. I also agree and
appreciate Kevin Spencer's analysis and idea of riding the curl of the wave
of progress (as opposed to the edge of the wave).

Re:
<< I don't see the relationship of the content to either "high standards" or
"low standards".>>

Perhaps I abstracted his article to such a high level because I saw the
article - if you get away from the specifics - as encouraging the reader to
THINK about what they are doing... to NOT just blindly accept what's given
to you (by Visual Studio in this case); e.g., textbox1, textbox2, textbox3
but rather to come up with meaningful names; to really understand what is
required by any .NET project type and not simply accept all of the default
references and Using statements automatically included in any project. So,
how does "high vs low standards" fit in here? People with high standards
generally think and care about what they are doing and what life (or Visual
Studio in this case) presents to them - and then take some proactive steps
toward some consciously chosen end. People with low standards would simply
take the easy route out and blindly accept everything given to them - or at
least the path of least resistance as a matter of course. That's all.

-GH
 
Back
Top