PDA

View Full Version : Does Visual Studio Rot the Mind?



psychopath
06-20-2006, 08:49 PM
http://www.charlespetzold.com/etc/DoesVisualStudioRotTheMind.html


Abstract: Visual Studio can be one of the programmer's best friends, but over the years it has become increasingly pushy, domineering, and suffering from unsettling control issues. Should we just surrender to Visual Studio's insistence on writing our code for us? Or is Visual Studio sapping our programming intelligence rather than augmenting it? This talk dissects the code generated by Visual Studio; analyzes the appalling programming practices it perpetuates; rhapsodizes about the joys, frustrations, and satisfactions of unassisted coding; and speculates about the radical changes that Avalon will bring.


Good read, if you're interested.

SniperSAS
06-20-2006, 09:14 PM
I use dev-cpp because it is free :)

jverkoey
06-20-2006, 10:11 PM
"Sometimes the computer goes so haywire that it does something that no sane human would ever dream of doing such as starting a war."

That quote is priceless. :D

VirtualAce
06-21-2006, 12:25 AM
Visual Studio is a good product, but you cannot let it write all of your MFC code for you. It does some rather 'odd' things at times.

The major downfall of the current version and of all previous versions is that it does not allow subclassing of custom classes.

In other words let's say I derive CMyTabCtrl from CTabCtrl. I want to stick CMyTabCtrl into a dialog resource. Well....you can't. You can only choose CTabCtrl. So you must manually go into the source and edit certain lines so that messages are passed to your control correctly. This is a major oversight.

I've mentioned this before but it also will stick 'public:', 'protected:' and 'private:' on the line preceding all your variables. In other words it doesn't group public, private and protected variables into clear sections. I'm sure this is a bug somewhere. The code ends up looking like this:




#pragma once

class CMyDialog:public CDialog
{
...
...
private:
CTabCtrl m_tabItems;
public:
CListBox m_lstFolders;
protected:
CButton m_btnOk;
public:
CButton m_btnNext;
...
};


Talk about ugly.

Thankfully they did get rid of that stupid



#ifndef 5958349535385934aJSOKSJGSKGJGKFDJKLJLJkjgsgkdgjg54 93869685965_h
#define 5958349535385934aJSOKSJGSKGJGKFDJKLJLJkjgsgkdgjg54 93869685965_h

class ....
{
...
...
//Dont touch this moron
//end of dont touch this moron

//Don't touch this either
//end of don't touch this either
};

#endif //end of 5958349535385934aJSOKSJGSKGJGKFDJKLJLJkjgsgkdgjg54 93869685965_h

Mario F.
06-21-2006, 05:31 AM
I'm obviously not versed in C++, having just recently started to learn the language. However the same issues arise in other programming languages where the IDE makes an effort to simplify regular coding procedures by generating the ode for us.

I always found the time I spend tweaking the produced code to my liking/style, is very close to the time I would have spent writting the same thing from scratch. So I'm usually averse to use any wizards. Microsoft does have a long tradition of "writting code for us" and doing it in ways that makes hair grow on our backs. However, I do think their approach proves successful to those few that choose to not fight it, but instead shift their brains towards Microsoft programming practices.

Overall I think this was never a successful move from companies that provide IDEs. I find it actually somewhat ironic that while they spend a lot of time providing these features on their IDEs, those are almost never discussed as either good or bad features by software reviewers. They are actually ignored for the most part when it comes to decide what makes an IDE good or bad.

On the other hand, there's CASE tools. It's also ironic that for the most part these tools provide much cleaner code than the wizards provided by IDEs. It's true that wizards provide very little information to the IDE in comparison to CASE tools. The IDE has to make a lot of assumptious, but I'm yet to see a simple CASE tool fully integrated into the coding environment. Something that always stroke me as odd.

BobMcGee123
06-24-2006, 04:27 PM
and even this past summer, Hollywood squeezed out a little cinematic turd called Stealth


And they don't mention the terminator movies? *sigh* I love movies that speak of computer intelligence taking over...read age of spiritual machines by ray kurzweil

EDIT:
I just read the intellisense section...not only do I use that extensively, I actually bought an addon called visual assist from wholetomato software, which is basically intellisense on steroids :)

jmd15
06-24-2006, 05:26 PM
The scent of MFC is strong in this thread. A most replusive stench.

VirtualAce
06-24-2006, 07:15 PM
The scent of MFC is strong in this thread. A most replusive stench.


Only if you don't know how to use it.

jmd15
06-24-2006, 07:36 PM
Lol, I VERY MUCH prefer raw Win32 over it. I know how to use that quite well and I don't want to use MFC. It disgusts me. :p

Mario F.
06-24-2006, 08:03 PM
Just don't go about having a mild opinion. No, sir. The important thing is being passionate....

CornedBee
06-25-2006, 11:52 AM
Only if you don't know how to use it.
Even then. ;)

valis
06-25-2006, 03:46 PM
I VERY MUCH prefer raw Win32 over it. I know how to use that quite well and I don't want to use MFC. It disgusts me. I agree completely, I learned on MFC and then when I moved to the straight api it became much simpler to get things done (still ugly compared to something real, say--qt or gtk).

novacain
06-29-2006, 07:27 PM
>>The scent of MFC is strong in this thread. A most replusive stench.

I have written many commercial WIN32 apps and many commercial MFC apps.

Give me MFC any day. Its advantage is in quick development time.

Most of the time I have to have the app written and tested by yesterday and demonstrate it to the client tomorrow in some mining site hundreds of km from anywhere.

Most of the people who bag MFC also dislike VB. Both are excelent tools if matched to the right job.

For example when coding a COM interfaces (DLL) for an ASP web page (which is also being written) a VB/MFC test app can be written in minutes. Pure WIN32 can take hours....

VirtualAce
06-29-2006, 10:55 PM
Lol, I VERY MUCH prefer raw Win32 over it. I know how to use that quite well and I don't want to use MFC. It disgusts me.


MFC is a tool. If you prefer not to use the tool that's ok. But just because you don't like one kind of hammer, doesn't mean it's useless.

And let's be sure you don't like MFC for valid reasons instead of the fact that you probably have not used it much. Document/View architecture excluded, MFC is pretty much a straightforward encapsulation of the Win32 API. Yes they did some strange things at times, but for the most part...it kicks ass.

BMJ
06-30-2006, 11:52 AM
I'll always be a minimalist, always. :)

jmd15
06-30-2006, 03:30 PM
Most of the people who bag MFC also dislike VB.

Damn right.


..doesn't mean it's useless.

Never said it was, just said I hated it ;).

valis
06-30-2006, 04:47 PM
If I had to write a backend for an asp website I'd pick C# over VB

Mario F.
06-30-2006, 04:53 PM
If I had to write a backend for an asp website I'd pick C# over VB

Why, if VB.Net and C# only difference is the syntax?

dpro
06-30-2006, 04:58 PM
Because its the cool thing to use c# :)

In any event, as has been echoed in this thread, pretty much any programming language can be good if you put it in the areas it was designed for. No one forces you to use it :).

Besides how can you hate something if you never experienced it? You can dislike something without association, but hating requires a whole new level of experience beyond the mere existential quality of that something.

jmd15
06-30-2006, 09:21 PM
Besides how can you hate something if you never experienced it? You can dislike something without association, but hating requires a whole new level of experience beyond the mere existential quality of that something.
I've used MFC before and I don't like it. Period.

VirtualAce
06-30-2006, 11:58 PM
Based on the information under your logo there I'd say your experience with MFC has been a superficial one. MFC is extremely complex and when used correctly it is extremely powerful. I would venture to say that dev time in MFC as opposed to pure Win32 might be decreased by nearly 60% ...and yet it's still C++ and not VB. What more could a programmer ask for?

Win32 is not object-oriented but MFC comes very close to making it as OO as can be w/o re-coding the OS. Hopefully all this will change with a new operating system.

valis
07-01-2006, 01:48 AM
I find that for the standard controls the api is far faster because you aren't forced into anything--for advanced controls, complex structure (callbacks smash gigantic switch statements) or special stuff like office 2003 menus MFC is obviously faster because that's already setup for you. Still, to throw together a small app which doesn't need extensible I find it much faster to deploy with the flat api.

As for vb.net being the same as C#, that's not exactly accurate, it's true one has access to the same libraries, but C# exposes more the to programmer and grants greater freedom--it also has more operators (At least since I last worked with vb. Why would a language not have decrement and increment?).

Mario F.
07-01-2006, 06:08 AM
Why would a language not have decrement and increment?

Because it's not part of the language specifications?
The lack (or abundance of features thereof) is not the sole reason why one should choose a tool over another.

VB and C# have the exact same access to the framework. Sorry to dissapoint you. But they do. They have their own syntax and, as such, may provide different ways to reach certain goals. However, they are the same programming language being given in two flavours.

VB proved successful, even without decent memory management and with a laughable OOP. Even without the incrememt and decrement operators ;)

You had for many years a lot of companies making a lot of money providing VB software to their clients (don't argue with me on this please) and a lot of companies gettin their work done supported by VB based tools. My question is thus exactly what you think makes a programming language good or bad?

What It Offers? or What It Delivers?

VB.Net is another proof of the success of this language. Here you have a huge base of VB programmers being shifted into a new paradigm while maintaining their know-how.

jmd15
07-01-2006, 05:18 PM
Based on the information under your logo there I'd say your experience with MFC has been a superficial one. MFC is extremely complex and when used correctly it is extremely powerful. I would venture to say that dev time in MFC as opposed to pure Win32 might be decreased by nearly 60% ...and yet it's still C++ and not VB. What more could a programmer ask for?

Win32 is not object-oriented but MFC comes very close to making it as OO as can be w/o re-coding the OS. Hopefully all this will change with a new operating system.
Oh definitely. I have not had extensive experience with MFC but I've used it and used pure Win32 and Win32 came out in top in my opinion. I know you're big on MFC, but I'm big on Win32 :P. The best part about MFC is how it's more OO than Win32. I still favor Win32 for multiple reasons.

Mad_guy
07-01-2006, 05:56 PM
Whatever you think comes out on top, can't come out on top in all situations. I hope you realize this.

whiteflags
07-01-2006, 06:05 PM
That and you always say stuff like
> I still favor Win32 for multiple reasons.
but never tell CProg what those reasons are. So you aren't really helping us understand you; it's why Bubba still thinks your minimal experience with MFC affects what you're saying about it.

jmd15
07-01-2006, 06:14 PM
That and you always say stuff like
> I still favor Win32 for multiple reasons.
but never tell CProg what those reasons are. So you aren't really helping us understand you; it's why Bubba still thinks your minimal experience with MFC affects what you're saying about it.
Nobody asked for my reasons ;)

Mario F.
07-01-2006, 06:17 PM
Well... i am now.
What's your reasons for favoring Win32 API over MFC?

valis
07-01-2006, 06:52 PM
@Mario F.
I'm not disagreeing you have access to the framework, you'll see I noted you have access to the same libraries in my post. I just don't like how VB tries to hide details and: access to things like increment, decrement, bitwise operators, dereference, unsafe mode, and it's weakly enforced syntax and cryptic block structure.

I'm not going to slap my employer if that's how he/she wants it done (that's the only time I've had to use it), I just would still pick C# over VB (for the reasons outlined above).

dpro
07-03-2006, 12:30 PM
That and you always say stuff like
> I still favor Win32 for multiple reasons.
but never tell CProg what those reasons are. So you aren't really helping us understand you; it's why Bubba still thinks your minimal experience with MFC affects what you're saying about it.


Pretty much :)

The whole code bloat is an issue I admit. Perhaps some people feel the "slip-slap-bam" approach of MFC is not right, or complain about the speed of the app under MFC. Perhaps people feel dirty even using classes created by MS, who knows.

It works quite well when you don't wish to reinvent the wheel.

If you have used it once or twice, I can understand the initial dislike, as I too hated it for a bit, until I realized how much had been made for it. You can pick and choose what you wish to implement, or not. No one says you need pure MFC all the time. You can mix win32 with it, and no one is the wiser.