Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

Does Visual Studio make you stupid?

Does Visual Studio make you stupid?

Rate This
  • Comments 43

I know everyone's talking about this, but it IS a good question...

Charles Petzold recently gave this speech to the NYC .NET users group.

I've got to say, having seen Daniel's experiences with Visual Basic, I can certainly see where Charles is coming from.  Due partly to the ease of use of VB, and (honestly) a lack of desire to dig deeper into the subject, Daniel's really quite ignorant of how these "computer" thingies work.  He can use them just fine, but he has no understanding of what's happening.

More importantly, he doesn't understand how to string functions/procedures together to build a coherent whole - if it can't be implemented with a button or image, it doesn't exist...

 

Anyway, what do you think?

 

  • "Does Visual Studio Rot the Mind?"

    Have calculators rotted the mind?

    :-)
  • I am going to have to say yes and no. For the new programmer, yes it most certainly does. My nephew is in a Computer Science course in high school and is really interested in technology, now unfortunately I am the only one that can help him with his homework although it is interesting because I see a lot of myself at that age. I won a copy of VS Pro at my local user group and I already had it through my MSDN subscription so I gave it to him, only 15 year old I know developing with VS.

    Now I spend most of my time in code view in VS. He spends most of his time in a designer where he can drag and drop. Now he is the future of developers. He is constantly asking me how I know all the stuff I know. The other day we were having a conversation about things he should learn on his own, somewhere he learned that regular expressions exist but they are not teaching them that in class so I sat down and walked him through some examples. Anyway, he asked what else he should learn on his own that they wouldn't teach him in school, I said well eventually you should really learn assembly the root of all evil. He looked at me with disgust and said why on earth would I ever want to learn that. There is no dragging and dropping or anything in there you have to manually do all that.

    This I think is the problem, so many new programmers are not even aware of the struggles we had to go through to get to where we are. There is nothing like sitting at a Vax terminal at 2 am with a compiler saying "Syntax Error missing semi colon" and you screaming back at the compiler "Yeah but where"

  • My father (a now-retired programmer) remembers a co-worker who would declare:

    Assembler programming promotes brain rot! Unless you're programming in the raw hex code, you can't really understand what the computer is doing!

    So yes, these sorts of concerns have been going on for ages, and in general they don't win.
  • I don't think Visual Studio makes you stupid, but it certainly tends to push you towards a particular style and organization for your programs. One where you build things bottom-up and, as Larry said, "if it can't be implemented with a button or image, it doesn't exist." There's not necessarily anything wrong with that style, but I think a lot of people use it because Visual Studio makes it continent, rather than because it's the best way to build whatever it is they're working on.

    There's an old saying, "If the only tool you have is a hammer, every problem starts to look like a nail."
  • I think Petzold's comments aren't as black and white as many of the commenters here seem to paint them. There are pros and cons to using Visual Studio's features, and I think he, like other mature programmers, are trying to find the highlights in a big gray landscape.

    Abstraction and detail-hiding are great things. They let us be productive by freeing us to think at a higher level. That's a powerful tool in dealing with complexity--assuming your abstractions don't leak. Detail-hiding is great for coding, but lousy for debugging (one of my chief complaints of STL).

    Intellisense will quickly remind me that a certain function returns a HANDLE, but it doesn't tell me if the function uses NULL or INVALID_HANDLE_VALUE to signal an error. I've been around long enough to know that I've got to check the reference materials on these. Other programmers don't, and will blissfully believe Intellisense has improved their productivity while they incorrectly check return values.

    But many of the tools we use to deal with software complexity (e.g., VS code generators) are Band-aids that give us a handhold on complex systems. If the handholds are good enough, we postpone taking the time to simplify by refactoring. In the long run, though, only the only scalable solution to managing complexity is working relentlessly to reduce it.

    Use VS to start building a Win32, application, and look at the boilerplate code it inserts. It has errors. The return value of GetMessage in the message loop is not checked properly. Mischecking this value is such a common problem that the help writers have made a big point of it in the MSDN topic. The boilerplate also introduced globals, doesn't have consistent formatting, and doesn't seem to adhere to a single set of style guidelines. Nothing there reduces complexity. MS didn't abstract away the hard and tedious bits into a library. Instead they gave us imperfect sample code to use as a starting point.

    And so much of the VS productivity tools seem to be geared toward dealing with the GUI work that I suspect it's leading developers to tightly couple UI and program logic. This is not really productivity-enhancing, though it may feel like it at the time.

    I'll keep Intellisense, though.
  • Visual Studio doesn't make you stupid, but cheating your way to get things done without understanding how they work is why we have SO many crappy programmers out there. Programming is a TOUGH thing to learn and takes a LONG time. Visual Studio (VB was the initial culprit) allows you to jump right into calculus without learning basic arithmetic. Ask most programmers today who Von Nuemann is/was and they will tell you he was a German World War I fighter ace. You HAVE to know the fundamentals BEFORE you can use the shortcut tools. That's the problem Visual Studio is exacerbating.
  • It used to be that to be a good computer guy you had to know your way around hardware as well - as in you had a wire-wrap tool in a drawer somewhere and knew resistor color codes by memory.

    Nowadays I know plenty of talented programmers who wouldn't have a clue where to begin if you asked them to draw a basic logic diagram for, say, an adder. And it doesn't really matter that they don't know either.

    I see this as part of the muturation of the industry. People specialize and work at different levels of abstraction.
  • No, VS doesn't make you stupid. But it is getting better and better at delivering on one of Microsoft's long-standing goals: allowing non-programmers to write programs. That was what VB was all about from the beginning; we can't be surprised that it's successful with as much attention as it's received from Microsoft.

    We're seeing it on the kernel side too - the upcoming WDF architecture, with the kernel-mode driver framework, will be yet another step toward ease-of-coding, and yet another step away from an understanding of the underlying fundamentals of the OS.

    There is a reasonable question to be posed here: at what point does it become bad, in general (for society, not for Microsoft), for relatively unskilled coders to work on [kernel-mode] software? Microsoft is in business to sell development tools and kits; it should sell as many as it can. Good for Microsoft. But I'm skeptical that the "market will get it right" on this one, at least not without a bunch of broken software making its way into the world to make all our lives more difficult first. Things like Blaster have real consequences.

    "With great power comes great responsibility" - these tools are designed to deliver great power to people who are new to this, and may not understand or accept the great responsibilities.
  • I am of the opinion that VS (like anything else) is a tool. You can use it to your advantage, or shoot yourself in the foot.

    I see no problems in people using Intellisense, or using the designer generated code to write applications. It is not a bad thing, necessarily. I can remember back when I first got started doing GUI programming (first with X-Windows and then with VC) and honestly, it was a pain in the butt. Instead of focusing on my application, I was spending more time writing message loops etc. Not that it is a bad thing to do so, but it distracted me from my main task which was to write a small GUI application.

    I would be concerned if newbie programmers started depending on VS as a whole for developing their programming skills. For eg, I once had to interview a person, and asked him to write a simple liked-list algorithm, and he said that he doesnt have to do that anymore because there is the System.ArrayList to use! Thank goodness it was for a temp position and he was promptly dispatched!

    When I got started programming, I learnt things from the bottoms up, meaning assembly -> C -> datastructure/algorithms etc. I can see why VS would encorage a more top-down approach since most of the things like Hashtable/List etc are already available. Is this necessarily a bad thing, and encourages bad programming practice? I am not sure. I guess VS or no VS, most programmers learn some bad programming habits over time, and with maturity and experience, hopefully, they can question them and change them.
  • I write code that goes into a realtime embedded system and my development environment is unix and gvim. I've used VS in the past and while I was pleasantly impressed by intellisense I wouldn't trade the productivity I get from gvim for it. But I can see how somebody working on plain Windows code would like it.

    I don't care for the code generation stuff though. This seems like a poor tradeoff between short term and long term productivity. Sure, you are more productive in the short term but sooner or later you'll need to understand how stuff really works and I for one hate having to do that when I'm in a time crunch. Again, maybe if you are writing a generic business app you don't need to know what goes on behind the curtain, but I'd be willing to bet you are more hireable if you do.

    Thanks for the link!

    Andrew.
  • I think that there's a topic that you've touched on in the pat, Larry: in order to understand and use a system, you have to understand the layer under it.

    In the case of the graphical UI designer in Visual Studio, you need to understand the code that Visual Studio is hiding away from you in that big generated region. You have to know why it is adding events, what adding an event means, and how you can add and remove events if you wanted to. The test really is: if you had to, could you write a WinForms application without the designer?

    This test applies to all levels of abstraction. I use C++ every day. I should know what the layout in memory of a virtual class is. Given the disassembly view of my program, I should be able to give a reason for each line of code that the compiler has generated, and why it is either necessary or not. I should be able to understand how one might implement templates, virtual functions, multiple inheritance, and object allocation in assembly, and what these features would look like in memory.

    This doesn't mean I need to be an assembly programmer, or produce any assembly code, although that's a good way to test to see whether I really understand what's going on.

    This also doesn't mean that I need to understand how chips work on a detailed level. That's what the assembly programmer has to do. But what I'm building on, that I need to know in order to build further.

    The law of leaky abstractions applies, of course. There will be times that assumptions from the design of the chips bubble up to me (I'm thinking of endianness here.)

    So what should the C#, managed programmer know? She should know how the CLR works, what IL code is generated for her programs, and what the JITter will do to that code. For the CLR specifically, she should know how one would go about making the methods in the FCL: none of these are magic, though some require support from the CLR.

    Etc.

    So does Visual Studio rot your brain? Entropy is the fundamental natural process: yes it does, if you let it.
  • Odd, I made two replies this morning. Did I get moderated for some reason?
  • I disputed Petzolds arguments elsewhere so not going to copy paste here, but let's talk about...

    re: newbies

    It's not long ago since I started C# with VS. At first I just wanted to get fancy alpha-blend stuff work in the simplest of WinForms, but gave up eventually since it didn't get me anywhere. Then I took on the challenge of asynchronous socket programming, which took a while to grasp and eternity to get right in a rather unusual scenario. I haven't gone back to doing WinForms since I figured I had to learn threads and delegates first. And while I had UML and Java in school, coming from script languages made grasping OO at first a long process. Some of the errors one gets when one has little understanding of OO are quite intimidating to a total OO newbie. After few books and lot of blogs and samples I started to know what sample code was bad and what was good. Well thought out and designed samples are important so newbie won't get bad ideas if (s)he doesn't understand to question the sample code at every step. From the basic concepts, delegates were a pain to start getting right, less so I believe with VS2005 snippets and anon delegates etc.

    Now with all the new things like W*F, LINQ and Sparkle coming I find the challenges change a bit and newbies like me may get to avoid horrible ADO and WinForms, which I've avoided so far nicely. If only Intellisense had worked perfectly with XAML I'd have started with it already, but the lazy me waits for Sparkle now. Another matter is that coding without a lot of automatic completions is too much exercise for my bad memory and in certain foreign keyboard layouts < > () etc takes double-triple effort. If switching to VS automatically switched the kbd layout to a programming friendly one and back, then I'd consider learning another layout. :-)
  • Thursday, October 27, 2005 12:00 AM by Nicholas Allen
    > I thought it was decadent when I bought a
    > macroassembler so I didn't have to look up
    > opcodes in the 6510 reference manual. But,
    > I've never again wasted an hour
    > recalculating branch offsets to fit in an
    > extra instruction.

    Seems to me that if you need to fit in an extra instruction and if recalculating branch offsets is a necessary part of getting it done, you're going to have to do some of it by hand anyway.

    But again that's part of the point of letting mechanics be mechanics and teaching drivers how to drive. Yes we still need some people to be mechanics, but that shouldn't be everyone's priority.

    Thursday, October 27, 2005 10:30 AM by Jeff Parker
    > There is nothing like sitting at a Vax
    > terminal at 2 am with a compiler saying
    > "Syntax Error missing semi colon" and you
    > screaming back at the compiler "Yeah but
    > where"

    You had a terminal? With a backspace key that let you fix mistakes oh so easily? And I'll bet you had an insert key and a full screen view? Such a soft life you had. Wanna know what other things there are like that syntax error? Here:

    Unexpected end of file.

    So you know you had a missing brace, but where? You can get this error message from Visual Studio or you could get it from a Fortran compiler 50 years ago. (Oops, 50 years ago it would have been "err3" and you'd have to look up error 3 in a printed manual, because the computer didn't have enough disk space to hold all error message texts.)
  • Because I had to spend may a boring, sunny, afternoon in classrooms learning how to design ALU, registers, and other wierd digital circuits my concept is at the physical level.

    I visualise two numbers being added as

    [Why did they remove line drawing characters - I know - IBM used them]

    0 ------- l---------l --------1
    0 ------- l ALU l --------1
    1 ------- l l --------0
    0 ------- l---------l --------1
    l l l l
    l l l l
    l l l l
    l l l l

    0 0 0 1

    Which adds 0010 with 1101 as 0001 is the ALU code for add (on a 10Hz computer).

    Now if daniel doesn't visualise VB in this context I don't know how he could use it. If a C or assembler programmer also doesn't visualise it like this, how can they program as their frame of reference is the CPU rather than the heart of a CPU.

    I actually visualise electrons whizzing about.
Page 2 of 3 (43 items) 123