On programming skill

Published June 22, 2007
Advertisement
I've noticed an interesting phenomenon.

Many programmers in the C++ and .Net realm absolutely love Visual Studio, and extoll its virtues as an IDE to everyone they meet. Then there are others who are not so impressed.

Now, I personally like Visual Studio a hell of a lot, but not perhaps for the same reason as most bright-eyed newcomers to the programming world. You see, I like Visual Studio because I still remember the really early C compiler days (think Microsoft C) when you had to write your code in something hideous like Edlin or DOS-Edit, then exit, run a batch file that called the compiler, and hope the output didn't cover more than a screen or two so you could spot any serious errors at the top of the list.

(For you spoiled young folks, this was the era where a small mistake would cause the compiler to barf pages and pages of errors for the rest of the code file. If the "missing semicolon" error scrolled off the top of the screen, you're in trouble; you may be left chasing pages of spurious nonsensical non-problems until you finally locate that pesky missing character. Yes, we used to actually write software that way. I cranked out a couple of games like that before giving up and moving to Windows.)

So as far as I'm concerned, compared to the way Things Once Were, Visual Studio is a huge blessing. I've written an addin that collects some handy little tools that I use on a regular basis, and between that and memorizing a few dozen keyboard shortcuts, I can blaze along in Visual Studio being nice and productive. It sure beats the hell out of single-tasking and compiling with batch files. (For some reason - I think it was youthful ignorance - I always preferred batch to makefiles.)


This brings us back to those programmers who don't see Visual Studio in such a positive light. I've heard quite a few remarks about how crappy it is, how poorly featured it is, and so on and so forth.

Now, this naturally makes me very curious. I'm not the sort of guy to use a crappy tool when a better one exists right next door, especially if the better one happens to be free. I may be stuck with VS for work, but at least I can use this mythical Better IDE for my own personal projects, right?

So I inquire as to what this grand tool is that makes Visual Studio seem so horrible in comparison.


Here's the interesting bit: without exception, every single programmer I've ever heard bitch about Visual Studio's quality (in the last 3 years or so that is) is a Java programmer. Some of them are recent newcomers to .Net, especially C#. Some have decided they need to "get more advanced" and try out C++. Either way, a strong Java background is universal among these complainers.

And the better IDE? (Drumroll, please...) It's always a Java IDE. IDEA comes up quite a bit.

This, of course, raises an interesting question: what specific features of this IDE do these Java guys miss in Visual Studio?


I've only ever heard one answer: refactoring tools.



I'm not going to argue. Visual Studio has only mediocre refactoring tools. Resharper is pretty slick, but it's an add-in, not core VS functionality. If you're working with C++, you can pretty much kiss automated refactoring goodbye, because parsing C++ is comparable to stabbing yourself in the brain with a ball-point pen, in terms of enjoyment and sanity.

What's odd is that I have also noticed that extensive reliance on refactoring tools correlates very strongly with shitty programmers.


This is not to say that refactoring is bad, or that if you need to rearrange your code you're a bad programmer. As a matter of fact, a reluctance to clean up code that needs refactoring is also a strong a sign of a bad programmer. However, when you're so caught up in "automated refactoring" that you need to do it all day every day - to the extent that you actually choose your IDE based on its refactoring tools - you're doing something wrong.

It has been my observation that overreliance on refactoring is a crutch. These are the trial-and-error, cargo-cult people who just blindly gibber around in their code until it seems to work. I don't know why, but the Java camp seems to produce an awful lot of these kinds of programmers.


When you can easily rearrange your code in all manner of odd ways, it encourages you to write code without thinking about the actual design. By contrast, when refactoring your codebase is a pain in the ass, you have a huge incentive to design it properly the first time. Moreover, when you're not obsessed with moving little blurbs of code around a half-dozen files, one tends to invest more brain-effort into actually getting working code produced.


Of course I'm sure at this point the agile crowd has already stopped reading and is in the comments section spewing all manner of rage, because easy refactoring is of course essential to agile development, and we all know that agile is the One True Methodology.

Well, two things to that. First, as I'm sure I've revealed from my description of coding in the early 90's, I've been around this field a while. I've seen a lot of One True Metholodogies come and go, and hey guess what, none of them were actually worth all that much. I'm far from convinced that agile is really anything special. Sure, there's some good concepts there, but it's stuff that good programmers have been doing instinctively for decades anyways - and most of that transcends methodology to a large extent. But I'm not here to argue against the agile fad, especially not since it's (thankfully) finally dying down.

Secondly, let me reiterate that I have no issue with refactoring itself. I need to do a fair bit of it on a regular basis, and despite best efforts, things tend to grow beyond the initial design. That's OK. I'm not arguing that we should eliminate automated refactoring because refactoring is itself a problem.

My opinion here is that forcing refactoring to be done by hand encourages us to be much more careful with how we do it. I've seen frivolous and unnecessary refactors cause just as much trouble as poorly factored code; heck, I've made some of those changes before. I think we only stand to benefit from adjusting our habits to think more carefully on the initial design, and to think extra carefully before making huge, sweeping changes.



So there you have it. I have now concluded that anyone who complains about Visual Studio (at least on the grounds that it has worse refactoring features than their Java tool of choice) can be safely flagged as a less-than-optimal-quality programmer.
0 likes 7 comments

Comments

Driv3MeFar
Quote:Original post by ApochPiQ
It has been my observation that overreliance on refactoring is a crutch. These are the trial-and-error, cargo-cult people who just blindly gibber around in their code until it seems to work. I don't know why, but the Java camp seems to produce an awful lot of these kinds of programmers.


I blame the schools these days.
June 22, 2007 01:48 PM
Ravuya
Eclipse can't even rename symbols properly. It makes me want to stab people in the face.

I only ever use ReSharper for symbol renaming (and possibly code hints once I pony up the bucks for v3.0), because I don't particularly trust it to do anything hilariously complex (I tried Eclipse's "pull up interface" refactoring tool once, and then spent the rest of the day trying to figure out why it managed to pull a method out of a class that I hadn't even selected and wasn't even in the same package). CodeWarrior worked better for Java, and that was back in Sun's original release, with a defective Apple VM in tow.

Java just pretty much gives me a headache in general. It's been how many years and the API is still inconsistent and so much of the VM runtime behaviour undocumented?

But hey guys, Sun is coming out with JavaFX, the desktop version of Java we were all asking for in 1996! Take that, Microsoft!
June 22, 2007 02:34 PM
jollyjeffers
Visual Studio is my tool of choice. I use it on a daily basis at work and at home.

Eclipse is better.

Simply put Eclipse was "for developers, by developers." It showed - there were so many hundreds of features that on their own are seemingly insignificant but when put together just made me a happy, smiling programmer --> [smile]

Anyway, the crucial point is that Eclipse (at the time, 2004/2005 - v3.0 heading towards 3.1) could ONLY do Java. All the niceties and cool features just evaporated if you tried to do ANYTHING other than pure Java development - hell, even GUI work majorly sucked.

On the other hand, Visual Studio works for a huge number of tools and platforms (e.g. the windows mobile tools) consistently and easily. What you get in one language is mostly available in all languages, even if it is a bit simplistic at times.

Jack
June 22, 2007 03:47 PM
Telastyn
I have a perhaps odd perspective because I learned C# before Java (and am still a relative Java noob). For all the purported goodness of eclipse, I was highly disappointed. It seemed a lot closer to devcpp than msvs to me, things were overly complicated and unintuitive.

One of my coworkers recommended cutting edge Netbeans instead. It is better, and the way I've seen him use it ("oh, just let it auto-detect your includes!") is similar in vein, the IDE itself is pretty descent. Still not to the standard of MSVCS imo, but pretty good.
June 22, 2007 11:56 PM
Washu
I'll try and keep my agile non-sense angry spewage out of this...[grin].
Quote:Original post by ApochPiQ
I've noticed an interesting phenomenon.

Many programmers in the C++ and .Net realm absolutely love Visual Studio, and extoll its virtues as an IDE to everyone they meet. Then there are others who are not so impressed.

This is funny, I've met quite a few people who also find VS unimpressive but...(see a bit further down for the rest)
Quote:Now, I personally like Visual Studio a hell of a lot, but not perhaps for the same reason as most bright-eyed newcomers to the programming world. You see, I like Visual Studio because I still remember the really early C compiler days (think Microsoft C) when you had to write your code in something hideous like Edlin or DOS-Edit, then exit, run a batch file that called the compiler, and hope the output didn't cover more than a screen or two so you could spot any serious errors at the top of the list.

Lol, you're a n00b then. I remember when they used to just crash and take the OS with them (oh DOS1, how I miss thee). After all the years of programming in every concievable language I've come to one conclusion: compilers suck.
Quote:(For you spoiled young folks, this was the era where a small mistake would cause the compiler to barf pages and pages of errors for the rest of the code file. If the "missing semicolon" error scrolled off the top of the screen, you're in trouble; you may be left chasing pages of spurious nonsensical non-problems until you finally locate that pesky missing character. Yes, we used to actually write software that way. I cranked out a couple of games like that before giving up and moving to Windows.)

This is why your batch files would redirect to a text file, the problem with this was...it still ended up using memory, and your compiler would sometimes crash simply because it ran out of RAM to store the error messages in.
Quote:Here's the interesting bit: without exception, every single programmer I've ever heard bitch about Visual Studio's quality (in the last 3 years or so that is) is a Java programmer. Some of them are recent newcomers to .Net, especially C#. Some have decided they need to "get more advanced" and try out C++. Either way, a strong Java background is universal among these complainers.

And the better IDE? (Drumroll, please...) It's always a Java IDE. IDEA comes up quite a bit.

...they are usually linux programmers, who exole the virtues of emacs. Now, emacs is great, if all you like doing is writing text. But frankly, when you have to write LISP (old lisp at that) just to get anything remotely useful done...sorry, it's a piece of shit (old shit at that).
Quote:I'm not going to argue. Visual Studio has only mediocre refactoring tools. Resharper is pretty slick, but it's an add-in, not core VS functionality. If you're working with C++, you can pretty much kiss automated refactoring goodbye, because parsing C++ is comparable to stabbing yourself in the brain with a ball-point pen, in terms of enjoyment and sanity.

Understatement.
Quote:What's odd is that I have also noticed that extensive reliance on refactoring tools correlates very strongly with shitty programmers.

I haven't. Smalltalk programmers, some of whome I would probably guess are amongst the best in the world, tend to rely on automatic refactoring tools. There is also the find/replace problem, of which refactoring tools tend to solve very nicely.
Quote:
It has been my observation that overreliance on refactoring is a crutch. These are the trial-and-error, cargo-cult people who just blindly gibber around in their code until it seems to work. I don't know why, but the Java camp seems to produce an awful lot of these kinds of programmers.

Yes, overreliance on any tool (even VS) is a crutch, crutches are bad.
Quote:When you can easily rearrange your code in all manner of odd ways, it encourages you to write code without thinking about the actual design. By contrast, when refactoring your codebase is a pain in the ass, you have a huge incentive to design it properly the first time. Moreover, when you're not obsessed with moving little blurbs of code around a half-dozen files, one tends to invest more brain-effort into actually getting working code produced.

Disagree. I often design my code, write it following the design, and then find that by refactoring it I end up at a cleaner design that was not easily obvious at the start. In fact, one of the big things I've found is that patterns tend to evolve out of code as you refactor. Those patterns help to reduce coupling that may have been inevitable in the original design, simplify code in a variety of ways, and possibly reduce corner cases.
Quote:Of course I'm sure at this point the agile crowd has already stopped reading and is in the comments section spewing all manner of rage, because easy refactoring is of course essential to agile development, and we all know that agile is the One True Methodology.

Now, I have to be honest: I don't practice agile. I use parts of agile that make sense: Refactoring, CRC, TDD, Acceptance Tests. Other parts I've tossed out because it got stuck in the same bucket as agile by people who aren't agile. That's the problem with jargon terms, they tend to lose their focus over time, and things that weren't part of the original definition end up in the definition.
Quote:My opinion here is that forcing refactoring to be done by hand encourages us to be much more careful with how we do it. I've seen frivolous and unnecessary refactors cause just as much trouble as po
June 24, 2007 12:15 AM
ApochPiQ
Quote:Lol, you're a n00b then.


[grin] There's always someone with a couple more years in the trenches. I'm glad I missed the really early DOS days; 4.x was bad enough. At least 5 was somewhat tolerable, for that era.

But yeah, compilers definitely suck. I remember segfaulting Visual C++ 2.x repeatedly when I first tried to use templates. I also remember 16-bit real-mode OSes where segfaulting meant rebooting and hoping you didn't have to run chkdsk to clean up roasted disk sectors.


Quote:Disagree. Basically, refactoring by hand will introduce more bugs than it will solve most of the time. Now, C++ has the problem that it's impossible to perform automated refactoring. However, cleaner languages (Smalltalk, C#, Haskell, O'Caml, etc.) tend to benefit from automated refactoring tools overall. People who refactor poorly aren't refactoring, they are just reodering code. Sorry but you can call it refactoring if you want, but that's a lie. Refactoring has a clear definition that is violated if the code produced does not meet a rather strict and small set of constraints.


I appreciated this bit in particular, because I learned something.

The distinction between refactoring and just scribbling around code is very important. I've always thought of it in fairly strict terms personally, i.e. the code must function equivalently before and after the change; refactorings must consist of what amount to identity transforms. It's like rearranging an equation to make it more amenable to certain types of analysis or further manipulation - think 90% of what you did in high school maths.

What I hadn't really connected before, though, was that this mindset is not universal. In particular, when I think about the people who motivated this little glob of bile, they don't hold that mindset.

It then becomes clear that these people aren't actually wanting to do refactoring; they're abusing refactoring tools to encourage their pre-existing habit of blindly hacking around in the dark until their code works.

So, in short, I got the causation exactly backwards. The symptom is still (IMHO) a useful diagnostic, but I'd misunderstood the disease.


Quote:Disagree. I often design my code, write it following the design, and then find that by refactoring it I end up at a cleaner design that was not easily obvious at the start. In fact, one of the big things I've found is that patterns tend to evolve out of code as you refactor. Those patterns help to reduce coupling that may have been inevitable in the original design, simplify code in a variety of ways, and possibly reduce corner cases.


Something that I didn't make particularly clear in the original piece is that this is also how I work. However, in my experience, it's very unusual to need more than one or two rounds of refactoring once the code is written. That is, I'll come up with a best-guess design, implement it, make a handful of changes, and then it's done.

By contrast, the habit I was whining about is much more extreme. We're talking dozens of rewrites and rearrangements, where it's obvious that 80% of the faffing about could have been avoided by just thinking out the problem. As a contrived example, someone writes a class using a std::vector for internal storage, then discovers the code performs like ass because there's a lot of insertions and deletions from the storage container. They then switch to a std::list and have to tweak a lot of little things. Then they realize they're going to need unique keys to identify items in the list (previously they used indices from the vector), and they cobble on some garbage to try and track the distance of a list node from the head of the list. Then they finally figure out that what they really should have done is just use a map in the first bloody place.

It's a hypothetical scenario, but sadly I've seen way too much of that kind of crap, all justified in the name of "refactoring" (which, as I've now realized, is a terrible misnomer). Since this process is clearly rather painful, automated tools would be a great benefit. But just thinking out the requirements and realizing that a map is the right container before writing any code is even more beneficial.

That's the distinction I had in my head, and totally failed to capture on paper [smile]


Quote:I haven't. Smalltalk programmers, some of whome I would probably guess are amongst the best in the world, tend to rely on automatic refactoring tools. There is also the find/replace problem, of which refactoring tools tend to solve very nicely.


I often lament the fact that I've never yet had the chance to work alongside a Smalltalk programmer. I suspect there's an awful lot of beautiful things I could learn from that language - probably fairly close to the kinds of insight I gained from hacking around in Lisp.

Whoops, here comes the torch-and-pitchfork mob!
June 24, 2007 09:30 AM
Tape_Worm
Quote:Original post by ApochPiQ
Now, I personally like Visual Studio a hell of a lot, but not perhaps for the same reason as most bright-eyed newcomers to the programming world. You see, I like Visual Studio because I still remember the really early C compiler days (think Microsoft C) when you had to write your code in something hideous like Edlin or DOS-Edit, then exit, run a batch file that called the compiler, and hope the output didn't cover more than a screen or two so you could spot any serious errors at the top of the list.

(For you spoiled young folks, this was the era where a small mistake would cause the compiler to barf pages and pages of errors for the rest of the code file. If the "missing semicolon" error scrolled off the top of the screen, you're in trouble; you may be left chasing pages of spurious nonsensical non-problems until you finally locate that pesky missing character. Yes, we used to actually write software that way. I cranked out a couple of games like that before giving up and moving to Windows.)


I won't get into the whole agile/refactoring/new fangled buzzword of the week arguments... Mostly because I'm not qualified to make any kind of remark on them I suspect.

I too remember the old MS/Borland/Turbo C compilers. And I remember using edlin and debug. I still have flashbacks.

So for you punks who don't know any better... he's not lying, a lot of people still have night terrors thanks to edlin.

I don't get it. I have tried other IDEs (not because I'm dissatisfied with Visual Studio, but just because I like to hurt myself). I can't see why people complain about Visual Studio, I mean if it's not your thing, great. Compared to the other IDEs I've tried, especially in linux where... well, we'll not open that particular door to hell again.

Compared to other IDEs I've tried, Visual Studio is what the others wish they could be. And that's not to belittle the investment of time the developers of other IDEs, they've done a great job in a lot of respects. But I find that a lot of them try to -duplicate- visual studios features. I feel that should tell you something. Sure, it has bugs. What doesn't these days? Given the complexity of it, I'm amazed it works at all. And those other IDEs I've tried aren't exactly super-stable. (For those who'd ask, I've tried out KDevelop, Anjutia(sp?), and SharpDevelop, and a few more over the years that I can't recall names on)

But really, the only thing I could see that would put some people out is the appearance (frankly I think it's fugly) and well let's face it, the bloat, of Visual Studio. Up until the express editions, the price was also a factor. But still these are very superficial reasons.
June 24, 2007 11:22 PM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement