A moderate view.

[Paul Mc]

G'day all.

Just thought that I would put my two cents worth out there - no doubt just
to cop a hammering ;-)

Regarding trends in recent discussion - ie with the pro-OO and OO-indifferent
camps battling it out etc - is the implementation of the added OO capabilities
in .Net truly the issue?

If these OO features were implemented into the classic VB environment, I
am sure the pro-OO camp would be cheering, the OO-indifferent camp would
shrug, and there would be no real contention.

Similarly, if the .Net rewrite of VB had taken place somehow without the
additional OO stuff, some would be pleased, many would
be displeased, and the situation would be pretty much same as what we have
now - though I imagine with fewer.Net supporters.

I think that the OO debate is to some extent obscuring things (of course
that is not to say you shouldn't debate it -go ahead! - I am just trying
to get myself clear about what is going on. Probably foolishly, I am doing
this in public). The core issues as I see them are:

1) The compatibilty issue - how difficult/possible/expensive will it be to
move my current codebase up? Can I rely on code to work the same(ie True
value, And)? Are the features I rely on still available(ie fixed length
strings)?

2)The knowledge investment issue. I think we can all say that we have invested
signifiant time, resources, and effort into developing our skills with VB.
Is this all wasted? Do I have to start again to move to .Net?

3)The cost/benefit isue. Given the costs incurred because of the previous
two points - what is the gain? Will those costs be recouped? How long will
that take?

From what I have seen, there is no denying that compatability is a real barrier
in the sense that codebase upgrading is quite time-consuming, and in many
cases must be thoroughly retested to be sure that it is still behaving in
the expected (relied on!) fashion. Also features have been dropped, perhaps
needlessly, perhaps not and this requires workarounds. Most damagingly of
all familiar features have been left in but altered - this is the most dangerous
change of all I think.

The knowledge investment issue is also a barrier - IMO perhaps more significant
than compatibility. In classic VB, given a problem to solve I usually have
an instant glimmering of (one possible way) how to go about solving it -
I know (to a certain extent) what VB can do, how to get it to do it, and
what it cannot easily do without API etc (note: I am not making claims to
be some master of VB - just to know my way around) I would guess that you
all have some comparable feelings. .Net-wise, I have not had too much trouble
getting a reasonable handle on most of the stuff that I have come across
so far - but I am not nearly as competent in .Net as I am in classic VB.


This all leads to the third issue, which is I think the true crux of the
matter. Moving to .Net IS going to take time/effort/resources ie money. What
are we going to get back out of it?

I guess that this is where the "To OO or .Not to OO" debate comes into the
picture. OO supporters (like myself) see the aditional OO capabilities as
a large part of the "payback" of making the move. Those indifferent to OO
obviously do not recieve this portion of the payback - the move is therefore
that much less likely to be rewarding for them. (Of course, one could argue
that there may be some flow-through from other object-designers work, but
this would probably not swing things much).

Then there is the web stuff. Personally I think it is great - I can imagine
a hundred ways to put web services into use, and from what I have seen, ASP.Net
seems to be fantastic (slightly off topic for VB I know, but many VB programmers
are doing ASP also...).


Additionally there is the unguessable payback of the CLF itself. I can of
course see advantages in this (electric dreams of VB running on linux on
top of a cross-platform CLR hee hee) - but this is at the moment pretty vague
to me.


Personally, as things stand in .Net Beta 1, I have to concede, to a degree,
the points made by most of the .Net detractors. For many of them, the immediate
disadvantages do outweigh the concrete advantages of the move. Similarly,
the pro .Net camp has valid points. For many of them, the move is worth it
- they see advantages that outweigh the disadvantages.

So what are we left with? The VB community is fractured neatly, and acrimoniously,
in half. The .Net detractors have valid points - and the most to fear. It
looks as if .Net will be here to stay, and classic VB will eventually be
dropped by MS. How can we (of course it will be MS not us personally doing
it - but we should at least try and find, and argue for, a better common
solution ) increase the payback - or decrease the cost - of .Net transition?
I like, to an extent, one suggestion, the "Option vb6Compatibility". I don't
know how possible that would be, and it would only adress part of the issue,
but it is a constructive start.

What else can we do? I am sure that between us we can find some answers,
if we can get past the rather pointless sniping.

Well there's my two cents. Fire away.

Paul

[Stephen Goguen]

Of all the stupid posts, you dare challenge us to take a moderate
stance on this issue!!! <no need to insert smilie>

Seriously, nice post... I think a lot of us tried to sum it up like
your
post, but got off on a serious tangent.

I hope your post generates a little discussion from both camps, so
we can figure out how to address the compatability issues while
not saccrificing the new design. Maybe we can begin to talk about all
the other compatibility issues other then True = -1, Short Circuiting, etc,
*and* how to address them.

Steve

> G'day all.
>
> Just thought that I would put my two cents worth out there - no doubt just
> to cop a hammering ;-)
>
> Regarding trends in recent discussion - ie with the pro-OO and
OO-indifferent
> camps battling it out etc - is the implementation of the added OO
capabilities
> in .Net truly the issue?
>
> If these OO features were implemented into the classic VB environment, I
> am sure the pro-OO camp would be cheering, the OO-indifferent camp would
> shrug, and there would be no real contention.
>
> Similarly, if the .Net rewrite of VB had taken place somehow without the
> additional OO stuff, some would be pleased, many would
> be displeased, and the situation would be pretty much same as what we have
> now - though I imagine with fewer.Net supporters.
>
> I think that the OO debate is to some extent obscuring things (of course
> that is not to say you shouldn't debate it -go ahead! - I am just trying
> to get myself clear about what is going on. Probably foolishly, I am doing
> this in public). The core issues as I see them are:
>
> 1) The compatibilty issue - how difficult/possible/expensive will it be to
> move my current codebase up? Can I rely on code to work the same(ie True
> value, And)? Are the features I rely on still available(ie fixed length
> strings)?
>
> 2)The knowledge investment issue. I think we can all say that we have
invested
> signifiant time, resources, and effort into developing our skills with VB.
> Is this all wasted? Do I have to start again to move to .Net?
>
> 3)The cost/benefit isue. Given the costs incurred because of the previous
> two points - what is the gain? Will those costs be recouped? How long will
> that take?
>
> From what I have seen, there is no denying that compatability is a real
barrier
> in the sense that codebase upgrading is quite time-consuming, and in many
> cases must be thoroughly retested to be sure that it is still behaving in
> the expected (relied on!) fashion. Also features have been dropped,
perhaps
> needlessly, perhaps not and this requires workarounds. Most damagingly of
> all familiar features have been left in but altered - this is the most
dangerous
> change of all I think.
>
> The knowledge investment issue is also a barrier - IMO perhaps more
significant
> than compatibility. In classic VB, given a problem to solve I usually have
> an instant glimmering of (one possible way) how to go about solving it -
> I know (to a certain extent) what VB can do, how to get it to do it, and
> what it cannot easily do without API etc (note: I am not making claims to
> be some master of VB - just to know my way around) I would guess that you
> all have some comparable feelings. .Net-wise, I have not had too much
trouble
> getting a reasonable handle on most of the stuff that I have come across
> so far - but I am not nearly as competent in .Net as I am in classic VB.
>
>
> This all leads to the third issue, which is I think the true crux of the
> matter. Moving to .Net IS going to take time/effort/resources ie money.
What
> are we going to get back out of it?
>
> I guess that this is where the "To OO or .Not to OO" debate comes into the
> picture. OO supporters (like myself) see the aditional OO capabilities as
> a large part of the "payback" of making the move. Those indifferent to OO
> obviously do not recieve this portion of the payback - the move is
therefore
> that much less likely to be rewarding for them. (Of course, one could
argue
> that there may be some flow-through from other object-designers work, but
> this would probably not swing things much).
>
> Then there is the web stuff. Personally I think it is great - I can
imagine
> a hundred ways to put web services into use, and from what I have seen,
ASP.Net
> seems to be fantastic (slightly off topic for VB I know, but many VB
programmers
> are doing ASP also...).
>
>
> Additionally there is the unguessable payback of the CLF itself. I can of
> course see advantages in this (electric dreams of VB running on linux on
> top of a cross-platform CLR hee hee) - but this is at the moment pretty
vague
> to me.
>
>
> Personally, as things stand in .Net Beta 1, I have to concede, to a
degree,
> the points made by most of the .Net detractors. For many of them, the
immediate
> disadvantages do outweigh the concrete advantages of the move. Similarly,
> the pro .Net camp has valid points. For many of them, the move is worth it
> - they see advantages that outweigh the disadvantages.
>
> So what are we left with? The VB community is fractured neatly, and
acrimoniously,
> in half. The .Net detractors have valid points - and the most to fear. It
> looks as if .Net will be here to stay, and classic VB will eventually be
> dropped by MS. How can we (of course it will be MS not us personally doing
> it - but we should at least try and find, and argue for, a better common
> solution ) increase the payback - or decrease the cost - of .Net
transition?
> I like, to an extent, one suggestion, the "Option vb6Compatibility". I
don't
> know how possible that would be, and it would only adress part of the
issue,
> but it is a constructive start.
>
> What else can we do? I am sure that between us we can find some answers,
> if we can get past the rather pointless sniping.
>
> Well there's my two cents. Fire away.
>
> Paul
>
>

[Patrick Steele]

In article <3af2bbae$1@news.devx.com> (from Stephen Goguen
<sgoguen@nospam.hormel.goeinc.com>),
> Maybe we can begin to talk about all
> the other compatibility issues other then True = -1, Short Circuiting, etc,
> *and* how to address them.

Don't you mean "AndAlso how to address them"...



--
Patrick Steele
(psteele@ipdsolution.com)
Lead Software Architect
Image Process Design

[Jonathan West]

Hi Paul,

I don't regard the "knowledge investment" issue as such a great one. Good
programmers are always learning new things, it's what makes them good
programmers. Learning them in VB.NET is not so very much different from
learning them in VB6 or C++.

The compatibility issue is a much bigger one. Not so much for programmers -
they'll get paid to write code whether it is new code or a rewrite. It is
rather an issue for companies faced with the prospect effectively of having
to pay their programmers to write the same application again before they can
proceed with further enhancement. This is a real cost to companies and might
well be a reason for some of them to avoid an upgrade of their existing apps
to .NET, and move elsewhere.

It has been generally accepted in the VB world that upgrading the language
will usually throw up some incompatibilities. Why this should be accepted is
beyond me, since other languages such as C++ have largely avoided this.

The key issue in the move from VB6 to VB.NET is how *much* incompatibility
is caused, and whether it was all strictly necessary. Given that Microsoft
is taking the opportunity with .NET to invent a whole new language C#, which
they can make as modern as they like and completely free of the oddities
necessary to maintain compatibility with old code, it seems that extreme
attempts ought to be made to maintain backwards compatibility for the
existing languages that will be on the .NET platform. With C++, they have
done this. (I have heard that one of Microsoft's tests of their .NET C++
compiler is whether it will successfully compile the code of Microsoft Word
to IL.) As things stand, Microsoft hasn't taken the same care of VB, and
this is why there has been so much screaming and shouting.

The three rollbacks so far announced show that some features introduced into
VB.NET beta 1 were not necessary either for compatibility with the platform
or for interoperability with other languages. Much more could be done to
improve compatibility without adversely affecting interop at all. The
diversity should be a positive advantage to Microsoft, in that they then
have, all sitting on the same platform, a language traditionally used for
shrinkwarp applications, operating systems and controls (C++), an thoroghly
modern language for new applications (C#) and a RAD tool able to bring a
large amount of code onto the .NET platform (VB). That would seem to be the
best of all worlds.

--
Regards
Jonathan West

"Paul Mc" <paulmc@nospam.thehub.com.au> wrote in message
news:3af1fb7a$1@news.devx.com...
>
> G'day all.
>
> Just thought that I would put my two cents worth out there - no doubt just
> to cop a hammering ;-)
>
> Regarding trends in recent discussion - ie with the pro-OO and
OO-indifferent
> camps battling it out etc - is the implementation of the added OO
capabilities
> in .Net truly the issue?
>
> If these OO features were implemented into the classic VB environment, I
> am sure the pro-OO camp would be cheering, the OO-indifferent camp would
> shrug, and there would be no real contention.
>
> Similarly, if the .Net rewrite of VB had taken place somehow without the
> additional OO stuff, some would be pleased, many would
> be displeased, and the situation would be pretty much same as what we have
> now - though I imagine with fewer.Net supporters.
>
> I think that the OO debate is to some extent obscuring things (of course
> that is not to say you shouldn't debate it -go ahead! - I am just trying
> to get myself clear about what is going on. Probably foolishly, I am doing
> this in public). The core issues as I see them are:
>
> 1) The compatibilty issue - how difficult/possible/expensive will it be to
> move my current codebase up? Can I rely on code to work the same(ie True
> value, And)? Are the features I rely on still available(ie fixed length
> strings)?
>
> 2)The knowledge investment issue. I think we can all say that we have
invested
> signifiant time, resources, and effort into developing our skills with VB.
> Is this all wasted? Do I have to start again to move to .Net?
>
> 3)The cost/benefit isue. Given the costs incurred because of the previous
> two points - what is the gain? Will those costs be recouped? How long will
> that take?
>
> From what I have seen, there is no denying that compatability is a real
barrier
> in the sense that codebase upgrading is quite time-consuming, and in many
> cases must be thoroughly retested to be sure that it is still behaving in
> the expected (relied on!) fashion. Also features have been dropped,
perhaps
> needlessly, perhaps not and this requires workarounds. Most damagingly of
> all familiar features have been left in but altered - this is the most
dangerous
> change of all I think.
>
> The knowledge investment issue is also a barrier - IMO perhaps more
significant
> than compatibility. In classic VB, given a problem to solve I usually have
> an instant glimmering of (one possible way) how to go about solving it -
> I know (to a certain extent) what VB can do, how to get it to do it, and
> what it cannot easily do without API etc (note: I am not making claims to
> be some master of VB - just to know my way around) I would guess that you
> all have some comparable feelings. .Net-wise, I have not had too much
trouble
> getting a reasonable handle on most of the stuff that I have come across
> so far - but I am not nearly as competent in .Net as I am in classic VB.
>
>
> This all leads to the third issue, which is I think the true crux of the
> matter. Moving to .Net IS going to take time/effort/resources ie money.
What
> are we going to get back out of it?
>
> I guess that this is where the "To OO or .Not to OO" debate comes into the
> picture. OO supporters (like myself) see the aditional OO capabilities as
> a large part of the "payback" of making the move. Those indifferent to OO
> obviously do not recieve this portion of the payback - the move is
therefore
> that much less likely to be rewarding for them. (Of course, one could
argue
> that there may be some flow-through from other object-designers work, but
> this would probably not swing things much).
>
> Then there is the web stuff. Personally I think it is great - I can
imagine
> a hundred ways to put web services into use, and from what I have seen,
ASP.Net
> seems to be fantastic (slightly off topic for VB I know, but many VB
programmers
> are doing ASP also...).
>
>
> Additionally there is the unguessable payback of the CLF itself. I can of
> course see advantages in this (electric dreams of VB running on linux on
> top of a cross-platform CLR hee hee) - but this is at the moment pretty
vague
> to me.
>
>
> Personally, as things stand in .Net Beta 1, I have to concede, to a
degree,
> the points made by most of the .Net detractors. For many of them, the
immediate
> disadvantages do outweigh the concrete advantages of the move. Similarly,
> the pro .Net camp has valid points. For many of them, the move is worth it
> - they see advantages that outweigh the disadvantages.
>
> So what are we left with? The VB community is fractured neatly, and
acrimoniously,
> in half. The .Net detractors have valid points - and the most to fear. It
> looks as if .Net will be here to stay, and classic VB will eventually be
> dropped by MS. How can we (of course it will be MS not us personally doing
> it - but we should at least try and find, and argue for, a better common
> solution ) increase the payback - or decrease the cost - of .Net
transition?
> I like, to an extent, one suggestion, the "Option vb6Compatibility". I
don't
> know how possible that would be, and it would only adress part of the
issue,
> but it is a constructive start.
>
> What else can we do? I am sure that between us we can find some answers,
> if we can get past the rather pointless sniping.
>
> Well there's my two cents. Fire away.
>
> Paul
>
>

[Paul Mc]

G'day Jonathan,

>Good
>programmers are always learning new things, it's what makes them good
>programmers. Learning them in VB.NET is not so very much different from
>learning them in VB6 or C++.

I agree with you to an extent. I certainly think that transitioning from
VB to VB.NET is far easier than from VB to, say, C++. But I also see the
change from VB to VB.NET as a lot more effort than, say, VB5 to VB6. I guess
I may have phrased it badly, but the point that I was attempting to make
was that this transition will be significantly more expensive than with any
previous version of VB. We need to be clear on what we are going to get back
from it.

Also, I don't think it is quite fair to compare to compare a VB programmer
learning VB.Net, with learning C++. Most of us have been doing VB for years
- why should any new version be such a radical learning curve that it can
be likened to learning a completely different language? Is it unreasonable
to expect those years of experience to be directly applicable to any new
version?

One last point, I agree that good programmers are always learning new things
- much of what I have seen posted seems to be asking "Why do I have to learn
a new way to do something I have known how to do for years, and that has
always worked just fine?"

>The compatibility issue is a much bigger one. Not so much for >programmers
-
>they'll get paid to write code whether it is new code or a rewrite.

In many cases, this is true. But what about the self-employed programmer
who relies on his/her large library of already written/tested/proven code
to maintain profit margins? What incentive to move to .Net then, when all
of that trusted code would need to be rewritten/tested/proven?


>The key issue in the move from VB6 to VB.NET is how *much* incompatibility
>is caused, and whether it was all strictly necessary.

Personally, I am not as worried about whether it was "strictly necessary",
as how much advantage it creates. If there was a change made that was not,
strictly, necessary, but that resulted in some definable advantage for the
language, I would probably accept that. That is of course purely a personal
view though - I can see that many believe differently.

>an thoroghly modern language for new applications (C#) and a RAD tool >able
to bring a large amount of code onto the .NET >platform (VB). That >would
seem to be the best of all worlds.

Agreed. However, I certainly don't want VB to be ported only because it can
bring a lot of existing code in. I want VB to be able to operate as a thoroughly
modern language too.

Paul.

[T. Hoskins]

Paul, I really enjoyed reading your post.

Although it is debateable how successful or better OO software development
projects really are, the fact is that they are being done anyways. I really
don't think that there are a lot of .NET detractors out there. What most
developers such as myself probably object to the most is the possibility
of being forced to use the .NET platform and the "OO way" as their only technical
solution to a business problem.

OOAD, UML, predictive/adaptive methodologies, design patterns, and all the
other crap associated with OO development is not necessarily a better way
of doing things. Just about everything OO development has to offer is just
a rehash of what is already working for most folks. The truth is that OO
development is not a silver bullet solution and for small projects it is
definately overkill in my opinion.

Personally, I find OO development techniques to be very elegant and sexy.
However, I am not sure if most companies and their employees are really prepared
to use what it has to offer. To me the introduction of the .NET platform
as the only Microsoft development platform brings up a lot of issues (such
as cost) that go way beyond the syntax of a particular programming language.

I think what OO development and the .NET platform has to offer is a great
thing for the industry and if all I had to do was write source code all day
long I probably wouldn't be complaining. I can live with the possibility
of having to abandon a large library of already written/tested/proven code.
What I can't live with is the posibility that the OO way of doing things
might well be my only choice. Don't get me wrong, I think that for medium-to-large
sized software projects, that OO development is the way to go. However, I
also think that many of the things that are associated with OO development
are just too difficult or impractical to do on a small software project.
Writing use cases, coming up with good classes, building models, etc. are
really team oriented activities that require a lot of brainstorming.

Personally, I think that hybrid languages such as C++ and VB as well as RAD
development techniques will have a place in the software development community
for a long time to come. Many VB developers currently don't work on team
application development projects and fewer still will ever have the opportunity
to do any type of enterprise-level development.

[Unrelated soap box speech] If somehow emphasis on reducing the amount of
time and cost it takes to develop software could be shifted more towards
software quality issues such as maintenance and scalability (the two most
costly issues for almost any organization) as well as to extensive employee
training -- then perhaps many of the major problems facing this industry
would eventually get better.

[Jonathan West]

Hi Paul,

"Paul Mc" <paulmc@nospam.thehub.com.au> wrote in message
news:3af4ab54$1@news.devx.com...
>
>
> One last point, I agree that good programmers are always learning new
things
> - much of what I have seen posted seems to be asking "Why do I have to
learn
> a new way to do something I have known how to do for years, and that has
> always worked just fine?"

I think this is part of the point I was making about "necessary change".
There is much necessary change in the move from basing VB on COM to basing
it on .NET. As a result, some different ways of thinking ore going to be
needed, and some old workarounds will either cease to be effective or cease
to be relevant. Fine by me. No doubt new problems will be discovered for
which new workarounds will get invented. Also no problem. All part of the
learning experience.

The difficulty with what you have said is more psychological. The complaint
is being spoken from the point of view of "necessary change" and the issue
of code migration, but it is getting misinterpreted (deliberately or not) as
an unwillingness to attempt to learn new things.

>
> >The compatibility issue is a much bigger one. Not so much for
>programmers
> -
> >they'll get paid to write code whether it is new code or a rewrite.
>
> In many cases, this is true. But what about the self-employed programmer
> who relies on his/her large library of already written/tested/proven code
> to maintain profit margins? What incentive to move to .Net then, when all
> of that trusted code would need to be rewritten/tested/proven?

In this case, the programmer is his own management, and the management
concerns I described apply to such a person. I can see it causing hardship
to some independents as the value of the VB6 source depreciates.

>
>
> >The key issue in the move from VB6 to VB.NET is how *much*
incompatibility
> >is caused, and whether it was all strictly necessary.
>
> Personally, I am not as worried about whether it was "strictly necessary",
> as how much advantage it creates. If there was a change made that was not,
> strictly, necessary, but that resulted in some definable advantage for the
> language, I would probably accept that. That is of course purely a
personal
> view though - I can see that many believe differently.

I'll accept your formulation of the phrase. Changing the Integer and Long
definitions offers no functional advantage, and reduces the opportunity for
code snippets to be pasted into VB.NET projects. By your formulation, the
change creates no advantage. by mine its not necessary. I think we are using
different forms of words to describe much the same concept.

>
> >an thoroghly modern language for new applications (C#) and a RAD tool
>able
> to bring a large amount of code onto the .NET >platform (VB). That >would
> seem to be the best of all worlds.
>
> Agreed. However, I certainly don't want VB to be ported only because it
can
> bring a lot of existing code in. I want VB to be able to operate as a
thoroughly
> modern language too.

Well, yes and no. Once a language goes beyond version 1, it can never regain
its purity and elegance of design, just as most houses never look very
elegant once an extension has been built. You are always having to adapt and
in some ways limit the new in order to maintain compatibility with the old.
If you have an existing language into which people have made large
investments of knowledge and source code, then there is always some degree
of concern about bringing the old code and knowledge with you. It is only if
you are creating a wholly new language that this consideration does not
apply.

With VB.NET, there is a difference of opinion in the industry as to whether,
in beta 1, it is different enough to be considered to be a wholly new
language. Beyond that, there is a further debate as to whether the language
*ought* to be designed on the basis that it is a wholly new language. I have
heard viewpoints expressed on all sides of that argument. For what its
worth, my own view is that it ought not to be designed as if it is a new
language, (C# can fill that role) and therefore the rollbacks announced by
Microsoft are a small step in the right direction, but very many issues
still remain to be fixed in order to tackle the changes that confer no
advantage or inadequate advantage (unnecessary changes).


--
Regards
Jonathan West

[Kunle Odutola]

"Paul Mc" <paulmc@nospam.thehub.com.au> wrote in message
news:3af4ab54$1@news.devx.com...
>
> Also, I don't think it is quite fair to compare to compare a VB
programmer
> learning VB.Net, with learning C++. Most of us have been doing VB for
years
> - why should any new version be such a radical learning curve that it can
> be likened to learning a completely different language? Is it unreasonable
> to expect those years of experience to be directly applicable to any new
> version?

I think it is quite fair to compare VB->VB.NET to VB->Any-other-language
because ultimately, that is what we all did (or should have done) implicitly
before deciding to follow whatever subset of the
VB1->VB2->VB3->VB4->VB5->VB6 chain that applies. In this respect, VB.NET is
no different as it still presents the natural upgrade to VB developers on
the basis that converting to anything else is a much, more costly exercise
and the returns may not be any more significant than VB.NET can offer.
For those who offer RealBasic, TrueBasic etc as a better upgrade, remember
that VB6 still exists and for the time being at least is still a better
product than either (except on the cross-platform issue). That is why you
chose VB6 over them previously isn't it?

> One last point, I agree that good programmers are always learning new
things
> - much of what I have seen posted seems to be asking "Why do I have to
learn
> a new way to do something I have known how to do for years, and that has
> always worked just fine?"

If you decide to go forward with MS, you have to learn about the .NET
development and runtime platform. A new way of doing what you have done for
years...

> >The compatibility issue is a much bigger one. Not so much for
>programmers
> -
> >they'll get paid to write code whether it is new code or a rewrite.
>
> In many cases, this is true. But what about the self-employed programmer
> who relies on his/her large library of already written/tested/proven code
> to maintain profit margins? What incentive to move to .Net then, when all
> of that trusted code would need to be rewritten/tested/proven?

She would have had to rewrite and retest them all for the VB3->VB4-32
transition. This situation is no different.

> >an thoroghly modern language for new applications (C#) and a RAD tool
>able
> to bring a large amount of code onto the .NET >platform (VB). That >would
> seem to be the best of all worlds.
>
> Agreed. However, I certainly don't want VB to be ported only because it
can
> bring a lot of existing code in. I want VB to be able to operate as a
thoroughly
> modern language too.

You can't have it both ways. Some of your other comments suggest that you
want VB to remain like it has been and now...

Kunle

[Kunle Odutola]

"T. Hoskins" <thoskins@hotmail.com> wrote in message
news:3af5090d$1@news.devx.com...
>
> Paul, I really enjoyed reading your post.
>
> Although it is debateable how successful or better OO software development
> projects really are, the fact is that they are being done anyways. I
really
> don't think that there are a lot of .NET detractors out there. What most
> developers such as myself probably object to the most is the possibility
> of being forced to use the .NET platform and the "OO way" as their only
technical
> solution to a business problem.

I wouldn't use the success of OO projects as a yardstick to measure the
utility/usefulness/ROI of the OO paradigm. The success of individual
projects is far more dependent on the abilities and experience of the
practitioners involved than it is on the problem solving abstractions
employed. This applies equally to OO projects as it did to structured
programming, ADT and all the other abstractions that predate OO.

> OOAD, UML, predictive/adaptive methodologies, design patterns, and all the
> other crap associated with OO development is not necessarily a better way
> of doing things. Just about everything OO development has to offer is just
> a rehash of what is already working for most folks. The truth is that OO
> development is not a silver bullet solution and for small projects it is
> definately overkill in my opinion.

The is *no* silver bullet. All these comments apply equally to all other
problem solving abstractions.

What is undeniable is that the OO abstraction - based as it is on the idea
of a software system being a simulation of real worls systems - is more
"natural" and enables a wider range of people to be able to participate in
the analysis, design, development and testing of software systems. The
language is the same through all the phases of development. Only the level
of detail changes.

As for small projects, the size of a project is not a reliable indicator of
the likely returns of employing OO techniques and technology to the project.
The life time of the project and the possibility of reuse between this
project and previous or subsequent projects is a better one. If for a small
project you can build 70% (even 40%) of it entirely through reuse of
existing source code, frameworks or components, would OO still be overkill?.

> Personally, I find OO development techniques to be very elegant and sexy.
> However, I am not sure if most companies and their employees are really
prepared
> to use what it has to offer. To me the introduction of the .NET platform
> as the only Microsoft development platform brings up a lot of issues (such
> as cost) that go way beyond the syntax of a particular programming
language.

I would simply note that this issues haven't affected the Java platform in
the slightest...

> I think what OO development and the .NET platform has to offer is a great
> thing for the industry and if all I had to do was write source code all
day
> long I probably wouldn't be complaining. I can live with the possibility
> of having to abandon a large library of already written/tested/proven
code.

Not abandon. Refactor. You refactor the code into hopefully more reusable OO
entities. Or you just invent an OO abstraction for reusing the non-OO code
as it exists. You decide.

> What I can't live with is the posibility that the OO way of doing things
> might well be my only choice. Don't get me wrong, I think that for
medium-to-large
> sized software projects, that OO development is the way to go. However, I
> also think that many of the things that are associated with OO development
> are just too difficult or impractical to do on a small software project.
> Writing use cases, coming up with good classes, building models, etc. are
> really team oriented activities that require a lot of brainstorming.

I beg to differ. Use Cases are about requirements. Class models are about
domain analysis or logical design or implementation depending on the
context. This are essentiall activities in *all* software development
projects. You don't have to use those particular techniques but, you still
have to complete the activities they represent.

Pragmatism is a quality found in all the best minds in software engineering.
Since there is no silver bullet, you are free to determine just how much of
everything one learns or reads about is needed for your projects. You are
also free to substitute techniques as you see fit if it works better than
what Booch or Jacobson suggests you should do.

> [Unrelated soap box speech] If somehow emphasis on reducing the amount of
> time and cost it takes to develop software could be shifted more towards
> software quality issues such as maintenance and scalability (the two most
> costly issues for almost any organization) as well as to extensive
employee
> training -- then perhaps many of the major problems facing this industry
> would eventually get better.

OO when used effectively tackles maintanance quite elegantly IMO.
Scalability is a design issue that has been tackles very effectively with
infrastructural components such as MTS/COM+, MSMQ, HTTP, EJB, JMS, Stored
procs etc...

Kunle

[Mike Mitchell]

On Sat, 5 May 2001 16:26:42 +0100, "Jonathan West" <jwest@mvps.org>
wrote:

>I don't regard the "knowledge investment" issue as such a great one. Good
>programmers are always learning new things, it's what makes them good
>programmers.

But the "always learning new things" part needs clarification. Yes, I
learn new things in order to build upon what I already know about a
subject, in order to broaden my experience of, and with, that subject,
and in order to become a better and more productive exponent of it.
There is no benefit to the subject matter I am dealing with if I learn
new things unconnected with the subject. So, for example, if I am a
programmer in language X, then learning more about the many facets of
that language and how it interacts with the OS and how I might exploit
all of its more arcane features, then I am making better use of what I
already knew about X and thus the time spent on learning has huge
benefits to me (it makes me more of an exponent), my employer (I
produce greater productivity, enhanced product satisfaction, and
increased profits), and my users (who experience a well-rounded
product they can rely on to deliver what they expect, and more).

However, by learning a completely different language, such as Y, I am
diluting my experience and making it less useful, since my time is now
spent between X and Y (assuming I am not giving up X for ever). Also,
I am not bringing the knowledge won with X to learning Y, since Y is
so different, I have to learn from scratch and attempting to re-use
knowledge gained from X is actually more of a hindrance than a help,
as it creates confusion which acts as a barrier to learning the other
language.

> Learning them in VB.NET is not so very much different from
>learning them in VB6 or C++.
>
>The compatibility issue is a much bigger one. Not so much for programmers -
>they'll get paid to write code whether it is new code or a rewrite.

You imply that programmers, like ladies (and men) of the night, only
do it for the money. Yes, they get paid to write code, but real
programmers are the ones who would write programs even if they didn't
get paid, e.g. the free software movement. True programmers are those
who are fascinated by computers and the way that they may be
manipulated through a bunch of ones and zeroes. The money is an
additional benefit of doing a very satisfying job. The 'programer' who
is only doing it for the money is going to be an absolutely lousy
programmer. Programming is akin to a calling, such as the kind of
impetus that fires up the budding cleric or doctor.

MM

[Mike Mitchell]

On 5 May 2001 18:39:32 -0700, "Paul Mc" <paulmc@nospam.thehub.com.au>
wrote:

>In many cases, this is true. But what about the self-employed programmer
>who relies on his/her large library of already written/tested/proven code
>to maintain profit margins? What incentive to move to .Net then, when all
>of that trusted code would need to be rewritten/tested/proven?

Yes, no one can buy experience. I can go to the store and buy a carton
of milk. This avoids my having to raise and nurture a cow, find a plot
to put it on, and learn how to pull those teats. But in the case of a
programming language (or a real language) there is no alternative but
to obtain the plot, acquire a cow, and start squeezing. Experience is
very costly to acquire, both in terms of the financial outlay and the
amount of personal commitment it embodies. The .NET zealots will, I
suppose, just write off all of this experience and the huge knowledge
base it has wrought, like so much water under the bridge.

MM

[Kunle Odutola]

"Mike Mitchell" <kylix_is@hotmail.com> wrote in message
news:3af55cdf.2021920@news.devx.com...
> On 5 May 2001 18:39:32 -0700, "Paul Mc" <paulmc@nospam.thehub.com.au>
> wrote:

>
> >In many cases, this is true. But what about the self-employed programmer
> >who relies on his/her large library of already written/tested/proven code
> >to maintain profit margins? What incentive to move to .Net then, when all
> >of that trusted code would need to be rewritten/tested/proven?
>
> Yes, no one can buy experience. I can go to the store and buy a carton
> of milk. This avoids my having to raise and nurture a cow, find a plot
> to put it on, and learn how to pull those teats. But in the case of a
> programming language (or a real language) there is no alternative but
> to obtain the plot, acquire a cow, and start squeezing.

Not true. When you use the MsFlexGrid and myriad other controls in VB for
instance, your are just buying the carton in a drugstore not any of the
other stuff to do with animal farms in your analogy.

In fact because you don't have to develop the hardware, OS, development
tools and a zillion other things that you use as a developer, I'd say you
were much better off than the guy with the carton of milk. And yes, since
you already know it, the development many of these products was much easier
because of the application of OO technology. In some case, the products only
exist because of OO technology (the cost-to-build/benefit-from-product ratio
thing).

> Experience is
> very costly to acquire, both in terms of the financial outlay and the
> amount of personal commitment it embodies. The .NET zealots will, I
> suppose, just write off all of this experience and the huge knowledge
> base it has wrought, like so much water under the bridge.

Yes, _some_ experience is costly to acquire. The comments about segments of
..NET adoptees doesn't deserve an answer frankly...

Kunle

[Kunle Odutola]

"Paul Mc" <paulmc@nospam.thehub.com.au> wrote in message
news:3af1fb7a$1@news.devx.com...
>
> G'day all.
>
> Just thought that I would put my two cents worth out there - no doubt just
> to cop a hammering ;-)
>
> Regarding trends in recent discussion - ie with the pro-OO and
OO-indifferent
> camps battling it out etc - is the implementation of the added OO
capabilities
> in .Net truly the issue?

This is but one of the many issues that different people have with the .NET
experience. Note that by issue, I do not imply that is it a problem or even
a negative thing, just that it is a feature that people have an [strong]
opinion of.

> If these OO features were implemented into the classic VB environment, I
> am sure the pro-OO camp would be cheering, the OO-indifferent camp would
> shrug, and there would be no real contention.

VB was already an OO language. It's most glaring OO omission was white-box
inheritance. All VB users already used it's OO features (perhaps incorrectly
in some cases).

> Similarly, if the .Net rewrite of VB had taken place somehow without the
> additional OO stuff, some would be pleased, many would
> be displeased, and the situation would be pretty much same as what we have
> now - though I imagine with fewer.Net supporters.

Many people for whom full OO support was a requirement would have found
solace in C#. It wouldn't affect .NET adoption I believe, just VB.NET
adoption.

> I think that the OO debate is to some extent obscuring things (of course
> that is not to say you shouldn't debate it -go ahead! - I am just trying
> to get myself clear about what is going on. Probably foolishly, I am doing
> this in public). The core issues as I see them are:
>
> 1) The compatibilty issue - how difficult/possible/expensive will it be to
> move my current codebase up? Can I rely on code to work the same(ie True
> value, And)? Are the features I rely on still available(ie fixed length
> strings)?

It is prudent to remember that there is no requirement to move current
codebases. For the next release of VB, MS has effectively scrapped VB and
re-written a new virtualized development platform that most agree is a good
thing. It would be churlish to expect that with such a a redical re-write of
the underlying development platform, everything will just work the same.
Compare this to the VB3->VB4 upgrade and you'll see what I mean.

Of course everyone agrees MS hasn't done the best job possible (or more to
the point MS hasn't done it the way each individual would have done it)
because of the myriad changes that there has been to the syntax and
semantics of VB in VB.NET. I agree that some things are not what I expected
but VB.NET is still definitely an evolution of VB and not a new language.

>
> 2)The knowledge investment issue. I think we can all say that we have
invested
> signifiant time, resources, and effort into developing our skills with VB.
> Is this all wasted? Do I have to start again to move to .Net?

No. VB.NET is recognisably an evolution of VB. There are new things to learn
and old things to unlearn just like there as always been.
You will have to learn about a new platform (and it's API) though. That is
the price to be payed for access to .NET benefits.

> 3)The cost/benefit isue. Given the costs incurred because of the previous
> two points - what is the gain? Will those costs be recouped? How long will
> that take?

The gain?. Better productivity. Ability to write once and run on all Windows
platforms (and possibly other platforms in future though I won't bet on
this). Freedom to employ the language that offers the best problem solving
abstraction rather than just the ones that I can integrate easily with VB.
This is more the case for languages like Mercury, Haskell, ML, Scheme, Lisp,
Prolog etc.

Is it [likely to be] worth it?. Yes. I only answer for myself.

> The knowledge investment issue is also a barrier - IMO perhaps more
significant
> than compatibility. In classic VB, given a problem to solve I usually have
> an instant glimmering of (one possible way) how to go about solving it -
> I know (to a certain extent) what VB can do, how to get it to do it, and
> what it cannot easily do without API etc (note: I am not making claims to
> be some master of VB - just to know my way around) I would guess that you
> all have some comparable feelings. .Net-wise, I have not had too much
trouble
> getting a reasonable handle on most of the stuff that I have come across
> so far - but I am not nearly as competent in .Net as I am in classic VB.

Give yourself a chance, .NET has not even been formally released yet. Your
mastery of the language and the platform will return in time as you become
more familiar with .NET and VB.NET.

> This all leads to the third issue, which is I think the true crux of the
> matter. Moving to .Net IS going to take time/effort/resources ie money.
What
> are we going to get back out of it?

See _my_ answer to Q3 above.

> I guess that this is where the "To OO or .Not to OO" debate comes into the
> picture. OO supporters (like myself) see the aditional OO capabilities as
> a large part of the "payback" of making the move. Those indifferent to OO
> obviously do not recieve this portion of the payback - the move is
therefore
> that much less likely to be rewarding for them. (Of course, one could
argue
> that there may be some flow-through from other object-designers work, but
> this would probably not swing things much).

All the MS languages on .NET were OO before they moved to the platform. VB
was not a full OO language and that has now been fixed. That is a part of
the payback but the addition of drop-dead gorgeous support for threading,
COM+ object pooling, prevasive support for attribute-based development and
deployment, full and easy access to the underlying platform, full parity
with other .NET languages and the possibility of OS independence etc. are
other paybacks. Note that much of these have nothing to do with OO per se

> Then there is the web stuff. Personally I think it is great - I can
imagine
> a hundred ways to put web services into use, and from what I have seen,
ASP.Net
> seems to be fantastic (slightly off topic for VB I know, but many VB
programmers
> are doing ASP also...).

ASP.NET and WebForms is the real crown in the "web stuff" as far as .NET is
concerned for me. Web Services are just another nead idea in the toolbox
HailStorm notwithstanding.

> So what are we left with? The VB community is fractured neatly, and
acrimoniously,
> in half. The .Net detractors have valid points - and the most to fear. It
> looks as if .Net will be here to stay, and classic VB will eventually be
> dropped by MS. How can we (of course it will be MS not us personally doing
> it - but we should at least try and find, and argue for, a better common
> solution ) increase the payback - or decrease the cost - of .Net
transition?
> I like, to an extent, one suggestion, the "Option vb6Compatibility". I
don't
> know how possible that would be, and it would only adress part of the
issue,
> but it is a constructive start.

I see we share a fondness for the idea of a VB.NET that can fully emulate
VB6 syntax and semantics on demand. It is a nice idea, but realistically it
ain't gonna happen. In that environment, I prefer a radical VB.NET because I
always have my copy of VB6 for exisitng stuff.

Kunle
VB: To infinity or the dump...

[Mike Mitchell]

On Sun, 6 May 2001 16:31:27 +0100, "Kunle Odutola"
<kunle.odutola@<REMOVETHIS>okocha.freeserve.co.uk> wrote:

>> Yes, no one can buy experience. I can go to the store and buy a carton
>> of milk. This avoids my having to raise and nurture a cow, find a plot
>> to put it on, and learn how to pull those teats. But in the case of a
>> programming language (or a real language) there is no alternative but
>> to obtain the plot, acquire a cow, and start squeezing.
>
>Not true. When you use the MsFlexGrid and myriad other controls in VB for
>instance, your are just buying the carton in a drugstore not any of the
>other stuff to do with animal farms in your analogy.

Yes, it is true. I wasn't talking about using MsFlexGrid, but learning
a computer language. I wouldn't be able to use MsFlexGrid in any
language until I had learned the language, as I would have no concept
of the product and would not know how to hook it into my code, since
there wouldn't be any code to hook it into.

That said, I remind everyone how beneficial the use of these cartons
of milk are. Plonk one on a form, fill in a few properties, put in a
line or two in an event handler, and the app is done. If this is OOP,
well, I just LOVE it to bits! How EASY it is to do that with classic
VB.

MM

[Kunle Odutola]

"Mike Mitchell" <kylix_is@hotmail.com> wrote in message
news:3af59b77.18047718@news.devx.com...
> On Sun, 6 May 2001 16:31:27 +0100, "Kunle Odutola"
> <kunle.odutola@<REMOVETHIS>okocha.freeserve.co.uk> wrote:
>
> >> Yes, no one can buy experience. I can go to the store and buy a carton
> >> of milk. This avoids my having to raise and nurture a cow, find a plot
> >> to put it on, and learn how to pull those teats. But in the case of a
> >> programming language (or a real language) there is no alternative but
> >> to obtain the plot, acquire a cow, and start squeezing.
> >
> >Not true. When you use the MsFlexGrid and myriad other controls in VB for
> >instance, your are just buying the carton in a drugstore not any of the
> >other stuff to do with animal farms in your analogy.
>
> Yes, it is true. I wasn't talking about using MsFlexGrid, but learning
> a computer language. I wouldn't be able to use MsFlexGrid in any
> language until I had learned the language, as I would have no concept
> of the product and would not know how to hook it into my code, since
> there wouldn't be any code to hook it into.

You need to learn a whole language to be able to use components like
FlexGrid?
Ahhh!. I can see the real problem now...

Kunle