On Thu, 16 Jan 2003 20:06:35 +1100, "Jason Sobell iGadget"
<iGadget_@hotmail.com> wrote:

>My sympathies go out to all VB6 developers who do not have prior Java or C++
>experience, because the .NET transition is a very hard one,


Oh? Not what I've been hearing from the .Netizens in this ng for
months, some of whom have even suggested that learning VB.Net is as
easy as learning classic VB. In other words, they had no real basis
for making such false claims but were merely talking up the new
language to try and hoodwink novices into becoming believers.

> but I disagree
>that it is 'unacceptable' to have major language changes.


I have never claimed that VB.Net should have been given an injection
in the birth canal, but that it came out and promptly gobbled up its
older sibling, classic VB. By all means allow Microsoft (yeah,
magnanimous to a fault, me!) to produce what ever it liked, but that
should *not* include screwing over existing programmers and businesses
which depend on VB for everyday operation. That was cavalier, extreme,
unwarranted and - still - reversible. By all means produce a new
language and call it PolkaDots.OnNakedBots for all I care. But one
must be able to have continuity - for EVAH, if need be - in one's
previous and current choices. Otherwise there *is* a real risk that
Mircrosoft or some other software company can come along in future
years and do exactly the same thing all over again.

> Core VB6 was a
>tiny part of the VB environment, and most of the functionality used was in
>COM objects included as references. ADO, networking, 3rd party controls,
>scripting, and a myriad of other commonly used functions were in these
>addons, and these have been replicated with different syntax into the .NET
>library.
>The biggest pain in VB6 code conversion is that we all tended to write such
>apalling VB6 code!


This is nonsense! Who is "we all", I have to ask? You are blaming the
lack of a suitable conversion tool on some spurious claim that classic
VB was always just thrown together? The whole point of a modern,
dynamic language is that it *can* be thrown together! We do not have
such rigid structures in other walks of life nowadays. No longer do we
build massive stone bridges where the structure is far larger than the
culvert that passes through it. We apply flexibility, lightness, and
clean design concepts just strong enough to fulfil the purpose. So it
must be with programming, too. We *should* be able to throw together a
few "pictures" (i.e. controls), provide minimum, if any, glue code,
and try it out. There is not a machine on the planet that has to be
designed to work out of the box without any adjustments. We always
build machines to be adjustable and flexible. The problem with .Net
and the whole way of thinking in OOP is that it is all so prescribed
and defined. Instead, we must imbue the machines themselves with more
intelligence so that they aid us. We do that with Automatic Train
Protection, for example, so that if the driver inadvertently passes a
danger signal the train is brought to a safe halt. Same goes for
software, or it should do. Instead of taking the concepts in classic
VB, then adding on reams of total oopification, the designers should
have made the language more amenable to allowing apps to be thrown
together. I mean, can anyone, hand on heart, really say it's more
*fun* coding in VB.Net than in classic VB? Even the diehard masochists
who defended the obfuscatory powers of C++ to the last semicolon found
themselves sidelined by businesses large and small, as the bean
counters suddenly realised how the wool was being pulled over their
eyes by a few Jolt-quaffing purists.

> It was so easy to quickly knock up an initial solution,
>then spend days or weeks modifying it to give a quality looking application.


Just as we take a jack plane and smooth a plank of timber, continually
trying it out to see if it's "right" yet. The dogmatic, oopificatory
approach is to have every single piece of wood passed through a
thicknesser which has been adjusted to within a thousandth of a
millimeter.

>If we had to scrap it and restart we know that we could write it in half the
>code, and make it more maintainable, but with VB6 we don't have to do that.


'Zactly! We can modify and improve the code, and because, lacking much
OOP, thank God, it is so much more amenable to change without
affecting the object "model", and we can quickly turn a pig's ear into
a silk purse. You're not going to convince me that the only successful
VB apps were ones which had been painstakingly designed from the
ground up over months and months before any coding was started. Sure,
that approach could and did work for the truly complicated and complex
apps, but when did a VB team ever set out to replace the Chicago
Baggage Handling System or equivalent? That kind of mammoth computing
project may have seen elements of VB being employed, but huge systems
like that are rare compared with the multitude of straightforward
business apps which were VB's forte where the business rules have been
known for centuries. The beauty of something like VB (and there's
nothing quite like it, not really) is its pliant nature, yet it is
continually hand-holding us in case we do anything really stupid -
like incrementing a pointer off the end of memory.

>When we try to port that code to a VB.NET environment we have terrible
>problems, yet if we had used VB.NET in the first place we would probably
>have been forced to do more planning and developed a more structured
>solution the first time.


And there's nothing wrong in that approach if you're using a language
which demands it, as you're now suggesting VB.Net does, but again my
plea is not to take away my previous tools! If they had simply allowed
VB to continue as a bona fide alternative, even with further
improvements and an open-ended "use by" date, then as time passed,
people would have been able to get to know VB.Net at their own pace,
not have it thrust down their throat.

> This is something that Java and C++ developers are
>used to, but VB developers are not.


But you say this as if to claim that the Java/C++ position is the
'preferred' one, and my inference is that the VB folk need to be
dragged kicking and screaming into that 'alternative' mindset. This is
missing the point of a Rapid Application Development language! It all
revolves around that word 'rapid'. In the modern workshop we mount a
fresh lump of metal into the lathe chuck, adjust the knife, push a
button, and bingo! Out comes a new piston, or a new camshaft, or
whatever. We are no longer hunched over our work like in the lathes of
old with micrometer in hand and oily rag in the other. We are using
technology to improve the whole process through effective use of
computers. One even sees this in the airline industry, where the
old-fashioned tug-on-a-rope cables of the Boeing school of airplane
design are being supplanted by fly-by-wire, computer-based controls as
epitomised by European Airbus Industrie. Yet while we are typing in
code, the computer is almost completely passive. (Oh, it can detect
'syntax error' - how marvellous!)

> Now we are forced to adopt the same
>design constraints, so what VB developers considered 'RAD' (i.e. don't plan,
>just drag, drop & bodge) is no longer a viable option.


Why does the pejorative 'bodge' figure in there? Why does RAD have to
be a bodge? Why not instead adopt minimal planning, dragging,
dropping, adjusting, and trying out as the norm? We know it does work!
We have the evidence of 12 years of traditional VB programming
throughout millions of businesses to show for it.

>Is this good or bad?


Rigid = bad. Flexible = good. OOP = rigid. Non-OOP = flexible.

> I reckon that 80%+ of VB6 developers will require
>extensive relearning to be able to do this, and this is not good for
>industry.


It's not good because it's costing industry a small fortune in extra
costs that they would otherwise not have had to pay.

> Perhaps MS should have retained VB6


No 'perhaps' about it! Of course this is what they should have done.
They still could!

> but put in place more
>'incentives' to move over, such as free additional controls or wizards that
>developers and/or companies would be attracted to. From teaching and
>consulting I know how much experience most industry VB6 developers have, and
>I can say that most would (and are) struggling terribly to get to grips with
>VB.NET.


Instead of blaming the VB programmers, who after all were and are only
using the tools sold to them over a decade or more, I blame the new
language and its platform for being so unnecessarily complex. As for
incentives, that's a bit like offering a drink to Kamikaze pilots
before their final flight into glory.

MM