Funny - most of the VB guys I work with tend to be in Camp #2, BUT I have seen many many (majority?) of VB coders stuck in Camp #1

We have an expression for it "He's writing VB3 code" - guys wirting procedural code, and ignoring objects - even in this day of .NET (and particularly back in VB6) - they never made the transition

Is there a camp that says "Coding is not too hard"?

If coding is too hard...

OOP a failure?  Interesting idea.  I know the transition for procedural code to objects killed Foxpro way back when

Some OOP stuff has not caught on for sure (inheritance etc) - but I can't see where encapsulation and the like has not.

I know that I maintain a LOT of legacy VB code, and you know one of the things that makes me most nuts?  No refactoring tools for VB6.  I see SO many cases of class envy, and routines that do more than one thing, just because it's a dog to refactor the code.

Like it or not, there is still a LOT of VB6 code out there.  Plenty of it is hard to convert to .NET because the parts that break are spread all over the place.  If we could refactor it FIRST, and get test fixtures around it, it would be a lot easier to migrate - ah the heck with it - I'm 50/50 VB.NET and C# these days...

OOP can work. Procedurally oriented coding can.  These programming paradigms  are just different ways organizing code into structures that encourage modularization and make complexity understandable. I personally like OOP but I've seen lots of procedurally oriented programs that put the 'average' OOP to shame. Generally every programmer I've ever met who was a good procedural programmer had no problem at all going to OOP.

The problem is not design techniques or development methodolgy. The problem is the people who use them. A large percentage of programmers find programming too hard because they lack the ability to think in logical, well ordered ways.  I don't expect this problem will ever be fixed with a tool or process.

It is amusing really. The effort to make bad programmers effective has resulted in tools that make good programmers very productive. It has also allowed bad programmers to make create disasters at breathtaking speed.

I knew what you meant by OOP a failure - as in the difference between theory and practice

I don't really know if its a training/mentoring issue (maybe) - or even an (and I hate this term) IQ issue

Most of us know that the Average Developer is 2 standard deviations above the norm in IQ - I wonder if true OOP put's it JUST a little beyond the reach of the average developer - that they have no problem using objects, but developing them is something else

WAY back when - in one of the now standard "software developer" books (I know it wasn't peopleware, but one book or another in that timeframe) it was pointed out that the average software developer of that era owned NO books on programming - and in fact, the mean was below 1, BUT the average developer who owned 1 owned something like 10-15

I'd assert that today, the ratio is not so much book - but some sort of measure of "how interested is the developer in his art?" - maybe programming blogs read?  Maybe books (still) - whatever.  You're still going to see a large ratio of "programmers who just keep programming", and "Programmers who are always trying to get better"

It's a self selecting group...

"It is amusing really. The effort to make bad programmers effective has resulted in tools that make good programmers very productive. It has also allowed bad programmers to make create disasters at breathtaking speed."

Hehe - Yeah, your right.

There is an old saw about an average developer being 10x than a poor one, and a great developer being 10x the average...

I remember on friend back when (in school) who I used to pair program with (back before the called it that) - in the era where you wrote your code out in pencil and paper, before you punched it on to cards....

She was always amazed that on a 2 week project, often for the 1st week, I did NO visible work - and then just sat down and wrote out 500-600 lines of Assembly in one session - she'd punch them in (correcting the occasional typo) and it would work - she could NOT understand how I did it.  I'd BET that most of the folks on this list can understand it - it's the difference between a young lady who said "I guess I'll never be a programmer" - and someone still doing it (mumble mumble) years later

Does anyone know if the old stat of "the average programmer only remains in the field 5 years" still holds true?

Charlie

With regards to OOP being  a failure, I think it's safe to say that the problem isn't with OOP itself. In fact, OOP is what made programming more accessable to quasi-programmers in the first place. They LOVE OOP, they just don't know it :-)

Here's what I mean: Nobody with half a brain cell today would write a windows form the way we did it back in the procedural VC days. Every programmer who started in VB/Access loves the way you can pop up a new Form OBJECT and drag a bunch of Control OBJECTS on it. They use objects all the time and would never want to abandon them.

The big issue we're looking at here is the difference between object consumption and object authorship. Object consumption makes programming a hell of a lot easier, even for people who can't think abstractly in object terms. Object authorship, on the other hand, requires a certain form of discipline and knowledge set. For basic OOP concepts that, while not pattern-perfect, would certainly clean up all that hack spaghetti code, it's not difficult at all. I used to teach OOP to college kids for years and they got it no problem, even the ones who didn't aspire to become programmers. I think the biggest downfall is that for generations, the teaching methods for incoming (and self-taught) newbie and quasi-programmers assumes that OOP isn't needed and doesn't teach any OOP techniques at all. Just look at most courses and even samples on the web. These programmers, mostly not knowing any better, simply "grow up" without the OOP knowledge set.

The difference between a programmer and a good programmer is that the good programmer isn't satisfied with just making something work. It has work efficiently and be easily maintainable as well. However, for most people out there, getting something to work is "good enough", and that's where they stop. So most of those quasi-programmers I speak of stop learning as soon as they are able to get something to simply work. And given that the learning methods they used don't address OOP from the beginning, they're stuck using non-OOP aproaches for years. Once that becomes ingrained.... well, when all you have is a hammer, everything looks like a nail.

kg2v,

<<I know the transition for procedural code to objects killed Foxpro way back when>>

Not so.  The transition from procedural code to objects did *NOT* kill FoxPro -- quite the opposite.  It lives today as a full-blown OOP product,  has a strong user base and a highly united user community.  It has fallen from favor in larger companies since Microsoft failed to market the product, choosing instead to pitch their home-grown technologies.

OK - it didn't KILL Foxpro - but it did cut that community in half - I had this discussion with Alan Griver at the time...

It's an amazing product - but when you look at the percentage of folks who went from FPIII to FPIV...

Agreed, there were some folks who didn't make the transition, and still haven't.

The big difference was (and is) that those who DID make the OOP transition didn't exclude those who chose to continue with their procedural development.  Many other user communities left those behind who wouldn't upgrade their skills -- the VFP community supported their efforts, and continues to do so.

BTW, YAG and I had a nice discussion when he did an on-site for our company about a month ago.  He cleared up a LOT about where things are headed, and reassured about the continued support and interoperability enhancement of the product.

<<when you look at the percentage of folks who went from FPIII to FPIV...>>

Just for clarification, there was no VFP 4 -- the version numbers went from 3 to 5 to match the other products and accommodate VFP's inclusion into Visual Studio 97.

You are right RE 3>5 - I forgot, I'm NOT a FP geek

I have not talked much with YAG since he went to Microsoft - back when he was in NJ, he wanted me to come in and start their VB group - I always wonder how things would have been different

I'm just saying that there is a LARGE percentage of developers who can't/won't make the switch to OOP - and I believe it's because they CAN'T

Man - sometimes I think I've been programming too long - details are starting to fall out of my brain - 25 years this year

<<I'm just saying that there is a LARGE percentage of developers who can't/won't make the switch to OOP - and I believe it's because they CAN'T>>

Absolutely true.  They'll never grok it, and they passionately resist anyone trying to help them do so.

<<Man - sometimes I think I've been programming too long - details are starting to fall out of my brain - 25 years this year>>

Know the feeling all too well -- it's 29 years for me this year (sheesh, has it *really* been THAT long??)(shaking head)

Before you go on, I'm specifically worried at the moment about "Logic Intensive Systems" here. Systems

@kgv2

Have you read this article?

http://www.codeproject.com/dotnet/CSharpVersusVB.asp

It's about culture of VB programmers. I think you may find it interesting in light of your comments (how many books do you have, blogs do you read etc.).

I have only two years experience as a c# programmer. The last week I was very productive using 'my backhand' after weeks of trying to come up with the 'best way' to do something. Now it just works, although I feel the code is not the most pretty.

How many years (generally) does it take to 'get' patterns and become a good object _author_?

Software Factories - Another Unlearned EJB lesson: http://andersnoras.com/blogs/anoras/archive/2007/02/24/software-factories-another-unlearned-ejb-lesson.aspx

Mike,

Yeah - I've read it - thankfully, the shop is going to move to C# this year - UPPER management decreed that all new dev would be in C# over a year ago - of course, my middle manager keeps giving them reasons we can't - we're just doing it behind his back

and we still support everything from VB3 on up

Oh - forgot to answer your second question - how long to "get" object patterns

Good question - the now classic patterns - you can pick up from books.  Of course, 15 years ago, no one was talking patterns, you just designed classes as best as you could.  I fooled with C++ back then a bit

I'll give you the take from a guy who watched the VB3 (no classes at all) to VB4 transition - classes, but NOT fully OOP (missing inheritance)

Some guys got it from the word go (if you run into John Murdoch, he's one of them) - some took someone like John to say "see - this is a better way - then they took off running - me, and a few of my co-developers.  Some took months - a year - till they got used to it.  Some still aren't there

In out little group of about 20 programmers - I'm known as the guy who is up on all the theories RE programming - and my bookshelf gets browsed regularly - I enjoy sitting down and groking the theories - I've got everything from the old BDUF "quality software measurement" type stuff up to the agile/XP stuff, and honestly believe that the best method of software design depends on the developers you have

I will admit to being "most comfortable" in VB - for a VERY strange reason - and it also says something about the VB culture

WAY back when - and I mean WAY back - in the early 1980s, there was a very small group of programmers writing "professional" code in Basic - Some of us got there through strange routes - I came into it from HP Basic for IEEE-488 bus control - which was the standard way to to IEEE-488 control.  One day National and CEC came out with an ISA card that allowed us to use PCs instead of HPs - and the natural choice was - BASIC

Anyway - there was this group of BASIC developers - we used QuickBasic or Microsoft PDS - some of us hung out on Compuserve in the MSLANGS forum, got razzed by the C guys (this was before Microsoft even had C++) and in turn, razzed them back.

Windows started making inroads - and a lot of us said "Oh well, time to get C, the SDK, and a copy of Petzold, and get to work"

Just as I was starting to get comfortable with C/SDK, there was this rumbling about a "basic for windows" - yep, you guessed it - VB 1.0.  I got my copy the day AFTER it was released (I was actually THE first person to order it from Microsoft.  Went on sale 8:00 PST - I was ON the phone at 8:00PST...)

It was a wild time - and I've never really looked back.

Watching VBPJ start, and become what it is now - watching Programmers Journal fold, Software Development go away - can't remember the Name of JD Hildebrad's other magazine at Oakley Press, but was a charter subscriber - so got to watch all the modern stuff unfold, but my fingers still like to type the "basic" syntax

When Microsoft  first introduced the Variant concept - there was a small group on the beta (refered to as the "softball team" - as it was 10 guys) who raised quite a stink - we wanted what is now "Option strict" - and we said it would be a big dis-service to VB.  Now, as a background - in the VB4.0 era, VB was NOT being developed in the programmers group - but under the Microsoft OFFICE group = the "VBA" era.  They wanted to make VB easier for everyone - this is where that bad culture came in - the "softball team" was told in NO uncertain terms to "shut up, test the product as is, or there are lots of other programmers who would love to be on the beta" (Note:  This was the closed beta)

If you can find the folks from that era - you'll find folks who DON'T have the typical VB culture - of course most have moved on - names like Karl Perterson, Deborah Peterson, Dan Appleman, Mark Novasoff - folks who's name's I'm fairly proud that I used to have my name used in the same sentence..

(and yeah - I remember the first Tech-ed - or was it the PDC - here in NYC)