VB6 to .net

[N1GHTEYES]

The IT Gods here at work have decreed (without reference to the engineers - as usual) that, in the desktop upgrade we will be getting in about a year's time, VB6 will be scrapped and replaced by .net.

I've got huge piles of VB6 code (snippets, libs, apps - all sorts of stuff) totaling, oh, I don't know, several hundreds of thousands of lines of code. I have not used .net, but I have heard that unlike 4->5 and 5->6, I can't just run my VB6 code in .net and expect it to work.

So, firstly, can anybody confirm / deny this statement?
Secondly, can anyone suggest a ballpark figure for the effort required (say, per thousand lines of code) to convert from VB6 to .net?

Once we lowly engineers have been told something will happen, it is usually set in stone, so the chance of my persuading them not to do this is slim, but does anyone have any killer reasons NOT to convert? Is there, for example, anything that VB6 does which cannot be done in .net (or which is slower, or more difficult etc).

Does anyone want to champion .net and tell me why it IS a good idea to change?

Is coding in .net RADICALLY different? How much of a learning curve is there for a (moderately) competent VB6 programmer to learn to use .net?

Basically, any light you chaps (and chapesses) can throw on this, either to equip me to argue against it, or to prepare for it, would be appreciated.

Thanks in advance,

Tony

 

[TipGiver]

It has been said many times. VB6->.NET projects is a very hard task. A strong advice is to start from scratch.
The benefits of OO programming are.. whatever they are. Although you have been told to move to .NET, the vb6 projects must stay in vb6.

 

[BobRodes]

Well, in theory, OOP is a great idea. Furthermore, there are reams of data wherein the idea works in practice, however not so much of these data reside in the world of software development.

IMHO: the OOP paradigm began in manufacturing, with the idea of creating systems of standardized parts. As history has shown us, the idea works very well. However, the process only works as well as whatever process of standardization has been applied. My current opinion is that the reason that OOP hasn't lived up to its promise is because the software community hasn't the will to form a consensus on standards, rather than because of some defect that inheres in the concept itself.

Bob

 

[N1GHTEYES]

Bob:

On the scale of big, widely available apps, where lots of collaboration can be hoped for, and where major re-use is a big factor, what you say is surely true.

Do you not also think that, on the smaller scale, there is an argument that OOP is just not of obvious benefit in some cases?

For example, I tend to do mostly modelling and data analysis. The potential advantages of OOP in modelling are obvious, because there is an intuitive mapping to that which is modelled. For the data analysis however, if you really insist on doing it via OOP, there are any number of ways to divide the problem into "objects", and, generally, none of them work any better then simply developing a library of useful analysis routines, to be called as appropriate for each particular analysis task.

Tony

 

[BobRodes]

Yes, Tony, I take your point. If all you are doing is developing your own library and reusing them in your own context, you may not need to create objects and the like. On the other hand, if you find that there exists a library of stuff that will already do exactly what you want, it would be nice to access its functionality via an interface methodology with which you're already familiar. This is the attraction of OOP, in theory.

If I may briefly "preach to the converted": the problem that OOP addresses is not the creation of the routines' functionality iteself, but how that functionality might be addressed in a repeatable and consistent manner. OOP is about encapsulating functionality and exposing it through an agreed-upon interface. The theory is that economies of scale result.

Ok. That said, the less scale there is, the less benefit results, which I believe is your point. However, I would also argue that things change, and judicious, proactive overengineering can result in code that lasts well through periods of growth.

Furthermore, economies of scale can be realized over multiple problem domains, meaning that if there is a problem that is consistent across a wide range of unrelated problem domains, a consistent solution to that problem will result in economies of scale for all domains containing the problem. For example, in the field of electronics, it's entirely possible to create, let's say, a radio, without using any common off the shelf components. On the other hand, there are a great many radios in use, all independently of one another, but all pretty much based on the same electronic design. Those radios then use objects (i. e. components) whose functionality is well known, and which expose that functionality through consistent and well known interfaces. Simply put, you can build a radio more quickly and efficiently by first going to Fry's and buying the components that you need, rather than making them yourself. This is not yet the case in OOP, but the theory is the same.

Perhaps in some future software manufacturing world, data access will be so standardized that software engineers will always use the same body of data access components, and plug them into applications in the same sort of way that electronic devices are manufactured now. If so, I submit that some variation of OOP will be an essential part of that process.

Bob

 

[N1GHTEYES]

[provocative comment]So... what you're saying is that, OOP is eventually going to be useful when we all agree to do everything the same way all the time?[/provocative comment]

Seriously though, I understand what you're saying, and I don't really have any strong feelings against the overall concept of OOP and it's potential usefulness. However, [rant]in this specific case (the few VB-using engineers at our place being forced, without consultation to switch to .NET) I'm not struggling to control my cries of joy[/rant].

I think there might have been a modicum of thread drift happening here (not that I don't think it was interesting or helpful), but nvertheless, this whole thread has given me a fair bit to think on, and some very good points to make when I beard the IT Gods in their lair.

Thank you everybody.

Tony

 

[BobRodes]

No, actually, what I'm saying is that OOP is going to be useful when we stop making a point of doing everything differently from everyone else.

 

[N1GHTEYES]

Oh, sorry. I thought you meant the cup was half empty. Whereas it's actually half full.

Tony

 

[tsh73]

N1GHTEYES, here - between half empty and half full - is the thin edge between pessimist and optimist.
You choose.

 

[BobRodes]

I'm a true optimist....my cup runneth over.