Another Language

[Steven Bell]

It all boils down to one thing: Learning a new language.

In essence, learning to adapt Visual Basic 6.0 applications (a majority of
which are client server) to "upgrade" to VB.NET is the same as learning a
new language.

So, why bother with an unknown like VB.NET? (Rhetorical Question #1)

Why not learn another unknown like C#? (Rhetorical Question #2)

Or a known language like Java? (Rhetorical Question #3)

I have been programming Visual Basic since 1994, am an MCSD with a focus
on Visual Basic. I have 18+ years in the programming industry and have now
moved up to being a CIO in a start-up venture. If I am having to figure
out where my software-development company is going to go with this stuff...well,
that's bad. It leads to: What will I have to learn and is it profitable
for me to learn it (i.e. is it worth my valuable time)? What will I have
to force my existing staff to learn? AND what kind of people will I be hiring?


An additional, and I might add: very interesting, side effect is whether
I continue with the MCSD program. The answer at this moment is a reluctant
no. The reason: I will not pay for my employees to re-take the entire plethora
of exams (they will have to do it now on the own time and money), I will
not do so (not worth my time, it has absolutely no bearing on reality anymore).

Finally, the majority of application work that I find (especially in the
Dallas/Ft. Worth area) is Visual Basic 6.0 client/server or browser/server
applications. VB.NET does NOT address this. At all.

There! I vented. Just and FYI for you career minded folk out there. I
am a consultant and employer and I see no immediate or future need for VB.NET.
If Microsoft insists, in this huge paradigm shift, then it looks like a
golden opportunity for another company to produce a VB look-alike. Perhaps
a cross-platform VB look-alike...ah, well, I can always dream.

Steven Bell
CIO
Momentium Technologies
Dalls, TX

[Rob Teixeira]

"Steven Bell" <sbell@momentiumtech.com> wrote:

[snip rhetorical vent]

>An additional, and I might add: very interesting, side effect is whether
>I continue with the MCSD program. The answer at this moment is a reluctant
>no. The reason: I will not pay for my employees to re-take the entire
plethora
>of exams (they will have to do it now on the own time and money), I will
>not do so (not worth my time, it has absolutely no bearing on reality anymore).

But you already had to retake the tests for previous versions every time
a new one came out. I don't understand how this is different?
To keep the VB certification current, you had to take the VB3.0, VB4.0, VB5.0,
and VB6.0 tests. If there was a VB 7 that looked *exactly* like VB 6.0 but
with some new additions, they you'd have to take that exam as well. So I
don't see the difference.
But to be honest, I've never seen the "reality" bearing of the tests in the
first. That's another ball of wax.

>Finally, the majority of application work that I find (especially in the
>Dallas/Ft. Worth area) is Visual Basic 6.0 client/server or browser/server
>applications. VB.NET does NOT address this. At all.

How can you possibly say that? What are doing with client/server or browser/server
in VB6 that you can't do in VB.NET?
VB.NET uses the Winforms namespace in the Framework, which is a drastic improvement
on the old VB "rich" client forms/controls package. Remoting in VB.NET is
far superior to DCOM. Transaction support is also much better and you can
take full advantage of COM+ since the product is free-threaded and supports
object pooling.

>There! I vented. Just and FYI for you career minded folk out there. I
>am a consultant and employer and I see no immediate or future need for VB.NET.

My opinion is far different, but I don't think we'd agree further unless
we get some common ground here.

> If Microsoft insists, in this huge paradigm shift, then it looks like a
>golden opportunity for another company to produce a VB look-alike. Perhaps
>a cross-platform VB look-alike...ah, well, I can always dream.

Perhaps, but I don't see a need for that.

If anything, someone will produce a cross-platform CLR and your VB.NET code
would work with that.

-Rob

[Mike Mitchell]

On 29 Apr 2001 05:49:23 -0700, "Steven Bell" <sbell@momentiumtech.com>
wrote:

>Finally, the majority of application work that I find (especially in the
>Dallas/Ft. Worth area) is Visual Basic 6.0 client/server or browser/server
>applications. VB.NET does NOT address this. At all.

Well, Steven, I keep telling 'em the same thing, but do they listen?
Do they hear? Know those three wise monkeys with their hands covering
their ears, their eyes, their mouths? Recognise a parallel here?

MM

[Mike Mitchell]

On 29 Apr 2001 06:05:13 -0700, "Rob Teixeira" <RobTeixeira@@msn.com>
wrote:

>
>>Finally, the majority of application work that I find (especially in the
>>Dallas/Ft. Worth area) is Visual Basic 6.0 client/server or browser/server
>>applications. VB.NET does NOT address this. At all.
>
>How can you possibly say that? What are doing with client/server or browser/server
>in VB6 that you can't do in VB.NET?
>VB.NET uses the Winforms namespace in the Framework, which is a drastic improvement
>on the old VB "rich" client forms/controls package. Remoting in VB.NET is
>far superior to DCOM. Transaction support is also much better and you can
>take full advantage of COM+ since the product is free-threaded and supports
>object pooling.

I dunno. What's a guy supposed to do? You show him all these goodies,
and *still* he likes classic VB more. What will it take to convince
him? Me? Thousands of others?

MM

[Paul Mc]

>Finally, the majority of application work that I find (especially in the
>Dallas/Ft. Worth area) is Visual Basic 6.0 client/server or >browser/server
applications. VB.NET does NOT address this. At all.

Well this gives me a giggle. VB.Net does not address browser/server apps
huh? Have you actually seen VB.Net?

>Well, Steven, I keep telling 'em the same thing, but do they listen?
>Do they hear? Know those three wise monkeys with their hands covering
>their ears, their eyes, their mouths? Recognise a parallel here?

Actually I recognise a parrallel. Perhaps not exactly the one you are attempting
to imply, ironically enough....

And yes, we do listen - well, read. It is just that we know otherwise - having,
you know, actually spent some time and effort to get to know the subject
matter.

Paul Mc

[Jay Glynn]

Steven,

> Finally, the majority of application work that I find (especially in the
> Dallas/Ft. Worth area) is Visual Basic 6.0 client/server or browser/server
> applications. VB.NET does NOT address this. At all.

Your not looking close enough. .NET in general address this in many ways.

--
Jay Glynn
Introducing .NET

[Zane Thomas]

On 29 Apr 2001 15:54:29 -0700, "Paul Mc" <paulmc@nospam.thehub.com.au>
wrote:

>Have you actually seen VB.Net?

Is there really any serious question?


---
Ice Z - Straight Outta Redmond

[Rob Teixeira]

You don't know that. He hasn't posted anything since.
But so what? I haven't shown him anything. I just told him about it. I'd
be skepticle too in his shoes. If he really IS smart, he'll see for himself,
then make an informed decision (unlike some people I know...)

If anyone still thinks that .NET is nothing but webservices, then there are
a few bridges I'd like to sell them. Of course, I also partly blame the MS
marketing machine for not properly presenting the product either. Still,
their mistake is no reason for anyone's continued and prepetual ignorance.

-Rob

kylix_is@hotmail.com (Mike Mitchell) wrote:
>On 29 Apr 2001 06:05:13 -0700, "Rob Teixeira" <RobTeixeira@@msn.com>
>wrote:
>
>>
>>>Finally, the majority of application work that I find (especially in the
>>>Dallas/Ft. Worth area) is Visual Basic 6.0 client/server or browser/server
>>>applications. VB.NET does NOT address this. At all.
>>
>>How can you possibly say that? What are doing with client/server or browser/server
>>in VB6 that you can't do in VB.NET?
>>VB.NET uses the Winforms namespace in the Framework, which is a drastic
improvement
>>on the old VB "rich" client forms/controls package. Remoting in VB.NET
is
>>far superior to DCOM. Transaction support is also much better and you can
>>take full advantage of COM+ since the product is free-threaded and supports
>>object pooling.
>
>I dunno. What's a guy supposed to do? You show him all these goodies,
>and *still* he likes classic VB more. What will it take to convince
>him? Me? Thousands of others?
>
>MM

[Larry Linson]

Gee, it's amazing to me that the proponents of VB.NET seem to be able only
to deprecate those who aren't thrilled with it, but not to explain _how_
it is better for, or makes it easier to develop, standalone and client-server
applications. But, I agree with the statement that it _does_ address standalone
applications, client-server, and browser-server applications, in its way.
(So do a goodly list of other tools, see below for some that I opted not
to use in the past.)

It certainly doesn't provide the compiled code that was such a terrific thing
not long ago when Microsoft got around to it, and a number of other useful
features -- like variants. It certainly does require an object-oriented view
if you are to make good (not just best) use of it. It certainly does require
a significant re-learning process. And, I'd emphasize again, no one has convinced
me that it addresses the standalone and client-server areas any _better_
than previous versions, and those are the ones clients have called on me
to handle since 1991. And, I am eager to be convinced... I keep being told
that it handles the "small stuff" just fine, but what I read, and what I
hear applauded, are all the things that make it better for huge, team-developed,
code-intensive, distributed applications.

Prior to 1991, I _was_ involved with Enterprise-wide, some international-in-scope,
distributed applications of enormous magnitude, even before IBM introduced
the PC (without a single "object" in any of those, FYI). But, after I retired
from IBM, I was quite happy to solve a different class of business problems
and I was quite happy to have tools like 'classic VB' and Access that would
let me solve them with a minimum of fuss and bother.

I'll say it again, because it's true: Microsoft has taken the most popular
and successful Development Tool of all time and turned it into just another
object-oriented language. If I'd wanted to develop standalone and client
applications in an object-oriented language, there were a plethora available.
But, I didn't opt for Delphi, I didn't opt for C++ Builder, I didn't opt
for JBuilder, for Pascal, for C++, or one of the others.

I'll say this again, too: object oriented tools can be very useful for code-intensive
environments, but my appreciation of VB and Access was because they didn't
_have to be_ code-intensive environments. I could be wrong, but it certainly
appears to me that VB.NET, by its nature, is going to be a more code-intensive
environment than classic VB.

VB.NET has pulled the rug out from under a very significant portion (while
I don't have figures, my guess from the user groups to which I belong would
be, the majority) of VB developers.

If VB.NET's not, as its proponents claim, a new language with a few familiar
statements, it is certainly much different than "classic VB". It is going
to cost those who move to it an investment in learning and adjusting their
'paradigm' to take advantage of the object orientation. I speak from long
experience: in my 43 years in the computer business, I've learned language
after language. The difference? Before, there was a _reason_, there was some
benefit to each, not just because "the language had to change" because the
vendor decided it should, nor because a group of elitists decided that it
had too many flaws, despite it being useful and perfectly well-suited to
the applications at hand. Always before, when I experienced this significant
a change, the vendor/author at least had the honesty to give the new language
a new name.

Perhaps, because of those long years, and, perhaps, because I saw the beginnings
of objects and wasn't impressed (because OO simply codified and partially
automated what had been good programming practices since the beginning),
I'll be dismissed as just another old codger who ought to give it up because
the world is changing around him. But, perhaps someone will see that the
old codger has lived through a few 'world changing around him' times, has
been there, done that, and got the T-shirt (which says, "Change for change's
sake isn't new, it's just bad.", said with apologies to Bill Vaughn for coopting
and reversing his refrain).


"Paul Mc" <paulmc@nospam.thehub.com.au> wrote:
>
>
>>Finally, the majority of application work that I find (especially in the
>>Dallas/Ft. Worth area) is Visual Basic 6.0 client/server or >browser/server
>applications. VB.NET does NOT address this. At all.
>
>Well this gives me a giggle. VB.Net does not address browser/server apps
>huh? Have you actually seen VB.Net?
>
>>Well, Steven, I keep telling 'em the same thing, but do they listen?
>>Do they hear? Know those three wise monkeys with their hands covering
>>their ears, their eyes, their mouths? Recognise a parallel here?
>
>Actually I recognise a parrallel. Perhaps not exactly the one you are attempting
>to imply, ironically enough....
>
>And yes, we do listen - well, read. It is just that we know otherwise -
having,
>you know, actually spent some time and effort to get to know the subject
>matter.
>
>Paul Mc

[Paul Mc]

>Gee, it's amazing to me that the proponents of VB.NET seem to be able only
>to deprecate those who aren't thrilled with it, but not to explain _how_
>it is better for, or makes it easier to develop, standalone and client-server
>applications.

Larry,

I was not deprecating the opposing camp for simply disagreeing - I was taking
issue mainly with the following statement: (Quote) "Know those three wise
monkeys with their hands covering
their ears, their eyes, their mouths? Recognise a parallel here?" (EndQuote)
<- this made in reference to those of us who argue the pro .Net case. Sound
particularly constructive to you? I replied that I hear them, I listen -
but do not agree.

I welcome and enjoy a good, technical disagreement. I do not repect arguments
along the lines of "I haven't really taken the time to fully understand it
but it looks quite different so it is a bad thing."

>I keep being told that it handles the "small stuff" just fine, but what
I >read, and what I
>hear applauded, are all the things that make it better for huge, team-developed,
>code-intensive, distributed applications.

Fair comment. The greatest advances IMHO are those that will be used in the
much larger, structured developments, specifically those that use the component
based paradigm. This arena is where the new OO features, cross-language
capabilities, and other stuff can really be taken advantage of.

As for small stuff, I do not see why the new capabilities cannot make life
easier. I have half rewritten my basic "small stuff" library into .Net -
mostly as a learning exercise. I found that I could do a many things in different
and exciting ways - but have not yet come across anything that I could not
do. Sure, it is going to take me time to capitalise on the changes, and really
understand them, but you can bet that I will. Just like with the current
VB incarnation.

Most of the VB.Net opposition takes two forms.

A) Is that the changes and different capabilities are not worth the lack
of backwards compatibility. I see this (who wouldn't) as a fair complaint.
It is certainly going to cost me a lot of time (read money) to make the transition.
Nevertheless, I personally disagree with this argument. I am willing to cop
the losses, because I like what I see, and enjoy the greater freedom and
flexibility that .Net is offering.


B) Is that sad kind of opposition to change because it is change. I have
no truck with this camp - they offer nothing constructive and are the most
likely to engage in vindictive personal attacks. This type of argument gains
nothing - it just enflames people.


Personally, I love Current.VB. It is a great language. I also love New.VB
-it is also a great language.

Paul Mc

[Larry Linson]

"Paul Mc" <paulmc@nospam.thehub.com.au> wrote:

> I was not deprecating the opposing camp for simply disagreeing - I was
> taking issue mainly with the following statement: (Quote) "Know those
> three wise monkeys with their hands covering their ears, their eyes,
> their mouths? Recognise a parallel here?" (EndQuote)
> <- this made in reference to those of us who argue the pro .Net case.
> Sound particularly constructive to you? I replied that I hear them, I
> listen - but do not agree.
>
> I welcome and enjoy a good, technical disagreement. I do not repect
> arguments along the lines of "I haven't really taken the time to fully
> understand it but it looks quite different so it is a bad thing."

I was not just speaking of your response, although I must admit that it certainly
was not clear to me that you were just responding to the "monkey thing".
And, I think there is some truth that _many_ of the VB.NET supporters do
_not_, in fact, acknowledge valid objections, but dismiss them as the maunderings
of those too dim-witted, or too lazy, to "move forward". I apologize if I
gave the impression that yours was the only one, but it did seem to me to
follow that pattern.

> As for small stuff, I do not see why the new capabilities cannot make
> life easier. I have half rewritten my basic "small stuff" library
> into .Net - mostly as a learning exercise. I found that I could do a
> many things in different and exciting ways - but have not yet come
> across anything that I could not do. Sure, it is going to take me time
> to capitalise on the changes, and really understand them, but you can

>bet that I will. Just like with the current VB incarnation.

I'll also have to admit that at least twenty or so years ago, I became jaded
on "doing things in different and exciting ways". I look for being able to
do something I can't do now (that I need to do), for being able to do something
that I do now simpler or quicker or easier, for something I do now being
a better something, or for a tool that does something for me that I now to
have to do for myself. Before anyone "calls me on the subject", no, I have
not installed and used VB.NET. I have read a good deal on the subject, I
have carefully examined a number of examples, and I've paid close attention
in a number of presentations about it. So far, I fail to see anything that
fits one of the categories I describe, for the kind of applications that
I do.

I've asked our local Microsoft developer contact to do a presentation to
the VB SIGs (of which I am a member) or the Application Developer Issues
SIG (of which I am co-leader) for a presentation on VB.NET for standalone
and straight client-server. We haven't been able to arrange that just yet,
though he continues to assure me that "it handles those just fine". Of course,
in my not-so-humble opinion, Access 97 and later and all the versions of
32-bit VB "handle those just fine", too.

I don't have any vested interest in investing time and energy to learn something
new that only does what I'm doing now, as well, but differently, particularly
if there's also a chance that it will do what I'm doing now, only not quite
as well. It is in this regard that I mention managed (tokenized) code --
I remember the "discompiler" for tokenized VB. It's only because no one has,
so far, given Access applications credit for being worth stealing that there
has not been one for the 'compiled' (tokenized) .MDE.

If I'd only wanted to do "different and exciting" there have been for a long
time that list of alternatives that I could have done. Some would have allowed
me to get "closer to the metal", but for solving general business problems,
usually database or, at least, data-based, problems, I don't need to get
closer to the metal. The only API calls that I use with any regularity are
those for GetOpenFileName and GetSaveFileName of the Windows Common Dialog
-- IMNSHO, as easy or easier than the custom control for WCD, and no extras
to include in distribution, and, occasionally the BrowseForFolder API. I
can, and have, used a few others, but my need is rare. I also do not find
them difficult to use, so wrapping them in classes does not seem to have
any benefit to me (as it is claimed to have for everyone).

To me, it is clear, for changes and different capabilities to have the remote
possibility of being worth the lack of backward compatibility, they must
represent to me an improvement. And, as I've described above, they seem,
at best, to allow me to do what I do as well, and, if not "at best", perhaps
not so well as I can now.

To me, it seems obvious, that whatever benefits .NET will bring to the VB
developer are going to be limited to the ones who do "code intensive" work,
and those whose applications or components will operate in the server-side
environment with .NET servers of various kinds installed. And, others far
more knowledgeable than I have questioned the benefits of .NET over some
other, e.g., UNIX with Java, etc., environments. But, clearly, what's being
touted is "server-centric" and it is not so clear that the people who buy
and use hardware and software are nearly as enthusiastic about that change
to the paradigm as the people who will benefit most from a move to "application
service providers". As for me, I have long been a "power to the users" advocate,
cheering and supporting putting power on the desktop, and chuckling behind
my hand at the futile attempts to replace the powerful PCs with network appliances.
I spent 'way too many years writing applications supporting dumb terminals,
glass teletypes, and even controller-programmed terminals such as the 3270
and 3790 family to be enthusiastic about a regression to "thin client".

> Personally, I love Current.VB. It is a great language. I also love
> New.VB -- it is also a great language.

Classic VB, is not "a language" by my definition -- it is a Development Tool,
one that includes a language, and I agree that it is a great Development
Tool. I do agree that VB.NET is only a language, but I believe it is far,
far too early to determine whether it will be a great one.

I certainly believe that it is going to have far fewer users/developers than
classic VB. I know many, and read of many others, who have no intention of
moving to VB.NET, and a good many others who, instead of re-learning almost
from scratch, are going to the .NET environment, but moving to C# instead
of VB.NET. Despite your and others' advocacy, it is possible that VB.NET
will not really maintain enough users to keep Microsoft interested in continuing
it. The Boys and Girls in Redmond demonstrated back in nineteen-ought-ninety-something
that lack of a groundswell will prevent a second release or continuing support
-- heard anything about VB-DOS lately? Did anyone ever hear about VB-DOS
2.0?

I certainly would expect those in the business of supporting and enhancing
Microsoft's software to be enthusiastic about it. Our colleagues who train,
and our colleagues who write libraries and controls have little choice in
the matter. For example, I do not, for a moment, doubt Zane's enthusiasm,
but considering the business that Mabry is in, would he not have to be at
least supportive even if he had some serious reservations?

[Gregor R. Peisker]

Hi Larry,

> I certainly believe that it is going to have far fewer users/developers than
> classic VB. I know many, and read of many others, who have no intention of
> moving to VB.NET, and a good many others who, instead of re-learning almost
> from scratch, are going to the .NET environment, but moving to C# instead
> of VB.NET. Despite your and others' advocacy, it is possible that VB.NET
> will not really maintain enough users to keep Microsoft interested in continuing
> it. The Boys and Girls in Redmond demonstrated back in nineteen-ought-ninety-something
> that lack of a groundswell will prevent a second release or continuing support
> -- heard anything about VB-DOS lately? Did anyone ever hear about VB-DOS
> 2.0?

If that analogy is to make sense, you'd have to liken VB-DOS to "VB7", not VB.NET.

Regards,
Gregor

[Gregor R. Peisker]

Hi Larry,

> It certainly does require an object-oriented view
> if you are to make good (not just best) use of it.

IMO, that is certainly not so. You can still write functional programs, and just "use" classes like
in old VB6 (though classes come up more often).

As for "best use", things are different, of course.

Regards,
Gregor

[Gary Nelson]

Gregor,

>
> If that analogy is to make sense, you'd have to liken VB-DOS to "VB7", not
VB.NET.
>

I believe both analogies are good. VB7 will exist just as VB-DOS 2 existed.
If MS continues putting more emphasis on C# than on VB.Net, which obviously
it will do, VB.Net will probably end up as VB-DOS.

At this moment any flavor of VB has a very uncertain future.

Gary

[Ian Lowe]

Hi, Larry,

<snip>
> ...I became jaded
> on "doing things in different and exciting ways". I look for being able to
> do something I can't do now (that I need to do),

There are many things that VB.NET gives you access to that VB6 doesn't.
However, your programmes don't _need_ this, any more than the procedural
programmes pre-classes in VB needed classes. However, the addition of
classes gave you increased power and flexibility. In the same way, the
addition of full threading support, structured error handling, and the rest
are not _needed_, but neither was a GUI.

> for being able to do something
> that I do now simpler or quicker or easier

Now here is where .NET can shine. Since I've started using .NET, I've found
that many things are much simpler than before. Whether its OO techniques
which needed to be faked or hacked in VB6, screen drawing, or one of the
dozens of other framework enhancements, .NET makes many, many things easier.

And don't be fooled by the apparently far more verbose syntax you may see in
samples or see others complaining about. Although the syntax might look
bloated at first viewing, once you've used .NET and gotten used to the more
OO approach, the syntax actually becomes very clear and clean.

> for something I do now being
> a better something, or for a tool that does something for me that I now to
> have to do for myself.

OK, how about control anchoring, multi-line statement completion, full
support for implementation inheritance freeing you from faking it using
hidden composition, forms-based centralised error handling (ie, you can
redirect all unhandled errors to a single procedure with a single
statement), xcopy deployment, and more. VB.NET, imo, adds significant value.

> Before anyone "calls me on the subject", no, I have
> not installed and used VB.NET. I have read a good deal on the subject, I
> have carefully examined a number of examples, and I've paid close
attention
> in a number of presentations about it. So far, I fail to see anything that
> fits one of the categories I describe, for the kind of applications that
> I do.

I highly recommend trying the Beta, especially after Beta 2 is released
(assuming that it is also a public beta). I have liked everything that .NET
has to offer so far, and have found that it makes programming easier, once
you learn the differences.

<snip>
> To me, it seems obvious, that whatever benefits .NET will bring to the VB
> developer are going to be limited to the ones who do "code intensive"
work,
> and those whose applications or components will operate in the server-side
> environment with .NET servers of various kinds installed.

By "code intensive", I take you to mean multiple programmers working on
"enterprise" level applications. I don't work in that world either, but
VB.NET will make my life easier. Xcopy deployment alone will save me tons of
time and free me from the paltry offerings available through HTML and
intranet systems.

<snip>
> Classic VB, is not "a language" by my definition -- it is a Development
Tool,
> one that includes a language, and I agree that it is a great Development
> Tool. I do agree that VB.NET is only a language, but I believe it is far,
> far too early to determine whether it will be a great one.

VB.NET is a language, development environment (the IDE's cool!), and
framework. You could certainly use VB.NET without the development
environment (via command-line compilers), but the IDE does/will add value.

<snip>

Ian.