Choices
-
ChoicesWow. According to this survey on SearchVB.com, 64% of respondents code in VB6. Granted this is a VB site, so perhaps most of the people reading the site are stuck in VB 6 jobs and that's why they visit the site, but still that's a good sized number. With .Net having been out for 3 versions of the framework and 6 years you'd think that many companies, at least 1/2, would have moved to VB.NET fulltime.
Especially with the lack of support for VB 6 now.
I certainly understand the need to continue using VB 6 for legacy applications since rewrites are expensive. I also understand the steep learning curve and the desire to not move away from something you know so well. It's human nature to get comfortable in one area. As geeks I'd think most programmers are interested in moving to VB.NET and other languages, but it's a big change and I can believe that it slows the migration away from VB 6.
One interesting thing in the survey was that most people prferred working in smaller teams. That way they get to wear more hats, handle more roles, and have a bigger impact on the project. I know that's a big factor in whether you really give yourself to a project or not. If it's small you can help architect, work on different aspects of the lifecycle, and see the project through to completion.
In large projects you get stuck with one little part. Which can lead to a boring, mind numbing, and frustrating work day. We need large projects and need people to do their part, but we also need to remember that people need excitement. Giving them a small project they can control here and there definitely helps to keep people interested and happy.
And employed with you.
Steve Jones
-
I 2nd the "work in small teams" part.
It also helps gain a bigger picture of the project so you don't go down a blind alley.
When I develop I try and put the end user's hat on so I code for what they are likely to want to do. As the old saying goes, walk a mile in another man's shoes.
I was actually asked in an interview "What benefits does moving to VB.NET give"?
I was so shocked that it took me a few minutes to answer it.
-
Personally, as a fellow geek, I would embrace .NET (not just VB) with open arms. Having been on a number of courses now for VB and SQL 2005, life has been made somewhat easier in certain respects for the humble developer (although beefier machines are now required to run the development environments
). And yes, the small team building idea is excellent.What is stopping the company I work for is "money" - the initial cost of licensing (as per usual) and the cost of the re-write (architecturally, hours to code/test/implement and also the training budget available).
The philosophy used at the moment is "if it isn't broken, why fix it?"....... to a technology that is now nearly 10 years old. As well as still supporting SQL 6.5
-
We have been having the debate for the past 2 years about rewriting our applications in VB.Net and we still don't have a great answer for it. Effectively we can spend a year rewriting and testing our applications to give us....the same product as we have now but it is in .Net. There is no business case for this at all. The time spent on rewriting something that already exists would be better spent on enhancing what we have using VB6 as this generates sales.
We will be moving across to .Net but only when our application needs a major change, and that major change will in all probability be driven by sales, not by a need to move up to the latest programming language.
-
That 64% who still code in VB6 doesn't surprise me. I've been at the same company for 10 years, where we wrote an OK VB6 app 10 years ago, and then an excellent VB6 app 8 years ago. I would love to get away from those VB6 apps. I have developed a hatred for VB6; its IDE is so primative compared to VB.NET. But, we have half the developers we did when we wrote those two apps, and I hate to say it but the caliber of developers now working for us is not what it was when we authored those apps all those years ago. So, we're stuck in a developers' hell of maintenance of patches and just keeping our heads above water. Fortunately, we've been able to convert portions of the oldest app to VB.NET and ASP.NET, and that has helped tremendously, but the original apps live on like Hydra as we struggle with herculean effort to kill them.
Doctor Who -
I understand that porting an application from mysql to sqlserver can take a huge amount of ressources. But can someone explain me really how hard it is to port from vb6 to vb7??? I mean it's not like going from a self coded database to sql server 2005. I imagine that there are some pitfalls but can there be that much work involved??
-
RGR'us, for us the issue is that one of our developers has a very hard time with OOP concepts. He just doesn't seem able to wrap his mind around them. Because of that, it is hard to convert our older VB6 apps to VB.NET. However, in his favor he does prefer the VB.NET IDE to that of VB6, so he might be won over by the developement environment.
Doctor Who -
Thanx for the info. I was under the impression that the conversion tool was not doing a really good job of converting to .net. I was wondering about those pitfalls but I see you have other problems
.However if your programmer has troubles with oop. I suggest you turn him into a dba somehow. Maybe he'll have a natural touch to work with set based operations
. -
That is a good idea, RGR'us (about trying to make that one programmer into a DBA). Set operations might really be more to his liking.
Thanks!
Doctor Who -
I also prefer VB 6 to .net. One reason is that because it is so old, it is fixed and unchanging; and it's not hard to find a 10-years-plus VB vet. The .net world is a moving target - first I bought 2002 Pro, then I needed 2003 C# for a project, then 2003 VB for something else, and now I've got the portion of VS 2005 that comes with SS2005.
One more advantage to VB 6 is that you don't have to wonder if they have the .net Framework installed (and the correct version, too) so deployment is far more involved than the originally-promised "xcopy deployment" that would end DLL hell. Now we're in the Framework hell, instead. Or you might say we're back to requiring the correct version of VBRUNxxx, yuck!
-
The question to me is always how productive can you be in a specific language...if VB .Net were as or more productive at RAD, then I'd think that the VB6 development community would have emulated a water balloon dropped on a thumb-tack covered floor...sploosh, and they were gone.
Instead, I'm getting more and more questions about VB6 programming across the 'net (the real one) from coders in India, China, Eastern Europe, et cetera, etc., etc.
Of course, I'm socially unacceptable to those committed to describing good coding practices in the artificially convoluted terms so popular among those locked in an OOPified worldview...a quote that describes my line of thinking can be found at http://www.developer.com/net/vb/article.php/1562831:
"Because object-oriented development originated in the academic world, it comes with a whole new vocabulary and a whole lot of complicated descriptions for pretty simple ideas."
My mistake, perhaps, was starting in Z80 assembler. Code to me was and is getting from point "A" to point "B" the fastest way possible (whether in terms of syntax or clock cycles) with the least obfuscation (whether in terms of program flow or of the terminology you must use to describe what you are attempting to do with any particular language).
I went to get an additional degree after I'd been in the field for years (a C.S. Bachelors; human resource types are so limited in their ability to quantify knowledge - according to their worldview, all I have to do to make faster than light travel a reality is to write it on a piece of paper).
I ran into a number of OOP professors...and learned early on that it was political suicide to question their knowledge or, worse, laugh when they said things that indicated they had no idea of what the compiler would do to their code, or how the processor would pipeline the resulting object code.
Which, finally, brings me back to why VB6 is so popular, and incidentally why (even beyond the extreme likelihood that your job will be off-shored) programming is losing its appeal as a career choice in the U.S.
Americans are generally builders and inventors, and they want to do things right in the shortest time possible. If ANY other field had attempted to obfuscate its objectives as thoroughly as OOP has programming, I rather doubt that the United States of America would exist.
If Ulysses S. Grant had had to tell his quartermaster to instantiate a class of gunpowder and a class of ball, and then his quartermaster had to tell Du Pont to insure that when they created a class of cartridge it inherited both gunpowder and ball and included a public overridable function of ignition, and then his field commanders had to train their troops to implement their rifle class's correct aiming method depending upon the range to the enemy (said rifle having hopefully inherited the correct cartridge class with the ignition method being overridden to reflect the type of percussion cap the rifle had inherited)while the rounds were incoming and the men and horses were dying ...
Well, I suspect the Union would have got its a$$ shot off discussing the nuances of polymorphism.
-
Well, I started teaching myself programming after VB.NET was out, so I went straight to that and never really learned vb6. So I can't comment too much on the relative merits of the languages, but as for Steve's other point of working in small teams, I have definitely enjoyed that!
In my current job, I was hired as a VB .Net developer, but I've been exposed to everything from web dev, excel and OLAP programming, reporting services, SQL development and DBA work (from dtatabase design and implementation to administration)... oh, and a whole gamut of hardware stuff because we didn't have a dedicated hardware guy for the first year that I worked here.
There's little chance I would have gotten experience of all those fields in a bigger team.
-----------------
C8H10N4O2
-
There can be a lot of work. Unlike older VB version changes, which were minor syntax and some new features each time.
Much of th IO has changed so completely that there is no automated way of ding it. It is necessary to analyze the old code down the figuring out what the original was trying to accomplish, then recreating that in an entirely new way.
New code in .net is not a problem once one understands the object model (which in itself can be pretty daunting). Moving an old non trivial app is rarely worth the work.
...
-- FORTRAN manual for Xerox Computers --
-
Thanx for the info... I'll keep that in mind when I'm asked to do that
. -
Choices,... I think not. Microsoft is the only one choosing. We are all forced to follow. The only influence we have is how long until we follow.
Going to .Net before 2.0 is mature is like going to SQL 2005 before SP4 is released/mature. A moving target, driving costs up.
My philosophy is why go to version 1.0 of anything unless you like being a lab rat. There is very little business justification for the latest and greatest, only geekdom positioning.
[font="Arial"]Clifton G. Collins III[/font]
ChoicesViewing 15 posts - 1 through 15 (of 22 total)
You must be logged in to reply to this topic. Login to reply