Is VB.Not still a BEGINNERS' language?

[Mark Burns]

The above is a question I have been (instinctively?) holding the answer out
to be an emphatic: NO!
I have even been going so far as to state that BASIC is no longer the
appropriate name for this new language, which Microsoft is calling Visual
Basic.Net, preferring instead the shortened acronym Visual ASIC.Net as being
more correct for this new language.

However, David Bayley seems to think the opposite, and the purpose of this
thread is to begin an examination of that question - hopefully from a
reasoned, academic angle.
So, please, do participate, but please try to leave the emotionally-laden
stuff at the door, and any/all personal invectives are expressedly
UN-invited to this conversation.

There, that said, I will begin this discussion with a recap of a thread from
the vb.dotnet.technical newsgroup entitled: "Resource Management in VB.NOT?"

>>>Begin Recap<<<
Kathleen Dollard-Joeris, Bob Butler, Jeff Piel & David Bayley had a
sub-thread on the C# "Using" syntax...
<Bob Butler>
If you are saying that using the proposed construct is only valid if you
have a reference to an object that can safely have the Dispose method called
at the end then it's probably a bad idea. It only handles a subset of the
DF issues but makes it look like DF has been restored and I think that'd be
confusing for a lot of people and lead to a great deal of misuse. If DF can
not be provided in a fully consistent manner then I don't think the language
should attempt it at all.
</Bob Butler>
<Me>
BINGO!!
That is precisely why I despise the dispose() pattern. It is half-assed and
half-baked.
In classic VB we USED to be able to rely on the refcounting semantics under
the hood to do a 100% good job - up to the point where we got fancy enough
in our code to bring circular reference problems into the mix.

This is simply no longer the case, and therefore the enitre resource
management topic/problem are much more important and significant to
lower-level VB coders than ever before. This represents a loss to the VB
world, not a gain.
</Me>
<Patrick Steele>
It's all relative.
One man's garbage (sorry for the pun!) is another man's treasure...
</Patrick Steele>
<Me>
....Not for the newbies it isn't!
Let me ask you this: Which language, VB6 or VB.Net (I'm artificially
limiting your choices to just those for discussion purposes, and for these
discussion purposes, assume that this question occurs 2 weeks after FCS of
the VS.Net - and all the "It's Beta" objections are gone), would you rather
put a newbie programmer in front of with an initial small-scale DB
application assignment on his/her first week of the job? You and they both
will be graded on speed of completion and the performance/stability of the
application produced, but THEY will have to do all the work, not you....?

</Me>
<David Bayley>
VB.NET of course. It is *SOOOOO* much more consistent and easier to learn
for the newbie.
That's what people are complaining about!!! They cleaned VB out and made it
superb for the newbie, but backwards-compatibility was thrown out the
window. Honestly, I started listing all the benefits but just snipped it
all, since the list just went on, and on, and on, and on.
</David Bayley>
<snipped Me>
<David Bayley again>
....the arguments for VB.NET were lots of small things that
individually didn't amount to much, but put it all together...
Essentially I felt myself having to justify every little change that has
been made in VB.NET (putting backwards-compatibility aside of course). I
think it will make a refreshing discussion, and the instinctive reaction of
a well tuned VB'er is to view VB.NET as "more complicated"...
</David Bayley>
>>>End Recap<<<

....which pretty much brings us current, save for a parting "Visual ASIC it
ain't!" shot David fired at me.<g>

Ok, David, Here's the floor, let's see that list of what makes VB.Net
"*SOOOOO* much more consistent and easier to learn for the newbie." than VB6
is...

[Mike Mitchell]

On Sat, 3 Mar 2001 22:43:53 -0500, "Mark Burns" <mark@iolofpa.com>
wrote:

>There, that said, I will begin this discussion with a recap of a thread from
>the vb.dotnet.technical newsgroup entitled: "Resource Management in VB.NOT?"

The trouble with this kind of topic, argument, discussion - call it
what you will, is that there is logic and there is cant. And ne're the
twain shall meet, unfortunately. This thread will inevitably descend
into name-calling and ideology. It's a shame, but there you go. It
will happen. The very moment someone says "You could do this in
classic VB" and someone else responds "That way is obsolete anyway,"
then you have the makings of a slanging match. It's human nature. I
suppose it's because we "programmers" just think too much, that's our
problem. We never look for simple patterns in other walks of life to
compare our lot with.

So there has to be another way to obtain the answer to your question,
one that has been stripped of all emotion. And therefore I suggest a
system of points. That is, first decide whether the product with the
most or with the least will be the "winner", and then draw up an
unequivocal scoring system to allocate points. Points would have to
awarded for marketability (of the product and of the programmer's
skills later), of transferrability (to other systems), to ease of
coding, comprehension, speed of execution, rollout, help file
provision, documentation, level of programmer competence (general
education), and a lot more things besides.

This will take time.

But only by planning this as a military manoevre will there be any
possibility of excluding the noisy, empty-headed responses so rife in
this ng.

MM

[Larry Serflaten]

"Mark Burns" <mark@iolofpa.com> wrote in message news:3aa1c683@news.devx.com...
> The above is a question I have been (instinctively?) holding the answer out
> to be an emphatic: NO!
> I have even been going so far as to state that BASIC is no longer the
> appropriate name for this new language, which Microsoft is calling Visual
> Basic.Net, preferring instead the shortened acronym Visual ASIC.Net as being
> more correct for this new language.
>

How about:

Common Language Adapted Syntax for System and Interface Control . Net

AKA: Classic.Net

<g>
LFS

[Bob Butler]

"Mark Burns" <mark@iolofpa.com> wrote in message
news:3aa1c683@news.devx.com...
> The above is a question I have been (instinctively?) holding the answer
out
> to be an emphatic: NO!
> I have even been going so far as to state that BASIC is no longer the
> appropriate name for this new language, which Microsoft is calling Visual
> Basic.Net, preferring instead the shortened acronym Visual ASIC.Net as
being
> more correct for this new language.
>

Working with a local VB user's group, hanging out in various VB newsgroups
and fielding a lot of VB/VBA questions at work I've dealt with a pretty
broad cross-section of VB developers. If you'll pardon the broad
generalizations I tend to see four different kinds of VB beginners:

A: they have used one or more other languages (C++, Delphi, Java, any
language that deals with objects) for a while on actual production code but
are new to VB and need or want to pick up VB for work

B: they are new to programming in general and have mostly academic
experience, if that, and are starting out as a programmer in a VB
environment (could also be people with experience in non-object-based
languages)

C: they are non-programmers who want to use VBA or who want to be able to
slap together something functional for themselves for their work

D: they are hobbyists who enjoy playing around with programming

When I look at VB.Net in comparison to VB6 my guess at the reactions is:

A: VB.Net is not bad; some pros, some cons, but overall the existing
experience and techniques can be moved into the VB.Net world pretty easily.

B: If the developer "gets" objects and how to design and use them then
VB.Net will look good; if not, it will be a confusing mess of rules learned
by rote and applied poorly

C: VB.Net is likely to be very daunting and if they use it at all they will
barely scratch the surface; most may stay VB6 or find some alternative

D: VB.Net will be too daunting and they'll move to something else


The strength I have always seen in VB has been that it was accessible to
those millions while still allowing experienced developers to create and
maintain good software quickly. It traded some power and performance for
simplicity and that was a reasonable tradeoff IMO. In trying to explain VB6
to new developers the main obstacle has always been getting them to fully
understand and implement objects. The upside was that you could still
create usable code in VB6 without a real understanding but I don't see the
same for VB.Net. I think VB.Net raises the bar too high for most of the
category C and D people and even possibly for many of the category B people.
I think that's a loss to the VB community.

[William Cleveland]

Mark Burns wrote:
>
> The above is a question I have been (instinctively?) holding the answer out
> to be an emphatic: NO!
> I have even been going so far as to state that BASIC is no longer the
> appropriate name for this new language, which Microsoft is calling Visual
> Basic.Net, preferring instead the shortened acronym Visual ASIC.Net as being
> more correct for this new language.
>
Whether or not it's an appropriate beginner's languge, it's still
recognisably based on the BASIC language tht came out of Dartmouth. I
don't BASIC has ever been the appropriate language for beginners; that
would be Pascal.

Bill

[William Cleveland]

Mark Burns wrote:
>
> The above is a question I have been (instinctively?) holding the answer out
> to be an emphatic: NO!
> I have even been going so far as to state that BASIC is no longer the
> appropriate name for this new language, which Microsoft is calling Visual
> Basic.Net, preferring instead the shortened acronym Visual ASIC.Net as being
> more correct for this new language.
>

I do think that there's a place for a higher-level langauge than
VB.Net, Delphi, Java, and VB6.

That would have reference counting *and* GC, and keep a linked list of
references, so that you can use a delete operator.

Objects variables that are declared and not initialized would have a
no-argument constructor called, and every class would automatically have
an Initialized flag (automatically set by constructors with
arguments?), so you'd check MyObject.Initialized instead of
"Not MyObject Is Nothing". More to the point, that check can be in the
class itself, as Me.Initialized.

Throw in some built-in data structures and make it interpreted-only,
and it'd be a nice little system for learning, prototyping, ad hoc
jobs, and application automation.

Bill

[Frustrated IT Worker]

Mark,

So the question you want people to respond to is "what makes VB.Net
*SOOOOO* much more consistent and easier to learn for the newbie."

If so, I don't how to properly answer this question. How do you define a
"newbie"? Is it someone who just graduated from college or is it a person
who has several years worth of mainframe programming experience under his
belt? Will the newbie programmer just be coding the initial small-scale DB
application or will he/she be doing it all so to speak. That is analysis,
design, implementation, testing, documentation and rollout of this application.


I don't think it is proper to compare the two somewhat similar programming
languages from a newbie perspecitve without first painting a very detailed
picture of who this person is (where they are coming from), the type of organization
they are working for, and what exactly will they be responsible for doing
on a software project. For example, if this person has just spent the last
four years in school studying subjects such as OOAD, Java and C++ programming
techniques, etc. then this person might find VB.NET easier to pick up and
understand than if this person had been doing structured design (data flow
diagrams, structure charts, etc.) and programming for the last four years.

Coming from a mainframe background, the way I learned how to do VB database
programming was by reading a LOT of books and magazines, checking out various
newsgroups, writing a lot of code on my own time, and generally borrowing
code written by other programmers. From my perspective, I would say that
VB.NET is not a beginners language but neither is classic VB since it is
what you can do with the programming language that really counts and not
how easy it is to create a simple application. Its all a matter of perspective
I guess, but the only thing that makes VB.NET superior to classic VB is that
you create more scalable component-based applications with it. Of course,
had Microsoft wished to do so, I think that they could have written the necessary
underlying code so that classic VB would have had a more robust threading
model.

I am not against OO languages in general. My problem is that most companies
are ill prepared for the transition to object-oriented technology in general.
What good is it to use a total OO approach to software development if only
a handful of people have the necessary training and experience?

"Mark Burns" <mark@iolofpa.com> wrote:

[David Bayley]

> The above is a question I have been (instinctively?) holding the answer
out
> to be an emphatic: NO!
> I have even been going so far as to state that BASIC is no longer the
> appropriate name for this new language, which Microsoft is calling Visual
> Basic.Net, preferring instead the shortened acronym Visual ASIC.Net as
being
> more correct for this new language.

I've been mulling it over, and I would like to put aside whether VB.NET is
suitable for "beginners" or not, and simply argue that it is easier to learn
than VB. i.e. if one accepts that VB is suitable for beginners, then VB.NET
is more so.

VB.NET reduces the number of concepts that need to be learnt, to one
consistant OO model. OOP is not a particularly difficult concept to
understand. A smart newbie will understand the abstractions in an
afternoon, and a dumb newbie might have to mull the ideas over a bit until
the abstractions sink in. The only difficulty with OOP, is when it comes to
analysis and design (OOA/OOD). This is when experience, understanding of
the problem domain, and intelligent abstraction is required.

Once that OO concept is learnt, then everything in VB.NET falls neatly into
the OO model. Let's compare this with some of the "wierd" VB concepts that
experienced VB'ers take for granted...

Forms
=====
This is the first thing a newbie plays with. In VB you have the wierd
concept of "hidden global" form variables for each form. Anything but the
most trivial app is going to require learning the nature of these hidden
form vars, followed by the realisation that you can declare and instantiate
normal form vars, and with a bit of experience you will simply ignore the
hidden vars altogether.

In VB.NET, the concepts are simpler. A form is a class, like any other
class, and you create new instances of them. This is just standard stuff
that the VB.NET newbie learns in their introduction to OO concepts. The
simplicity of VB.NET is further emphasised with that other "wierd" VB
concept whereby "Dim frm As New Form1" results in frm being magically
instantiated whenever the frm var is referred to.

Variants
=======
These wierd variables are simply not needed anymore. The OO model in VB.NET
rolls them into the one Object type. This is the root object that is learnt
during the introductory lesson on OOP. In VB, what exactly is the
difference between a Variant and an Object var, when they both refer to an
object? It's not an easy concept to explain to a newbie.

Control Arrays
===========
Another wierd VB concept that is simply not needed anymore. They're not
really arrays anyway, since the index is not actually an index, rather a tag
that gets added onto to event handlers and magically allows you to reference
them using array semantics. Sooner or later the VB newbie is faced with the
truth that "Arrays of Controls" are very different to "Control Arrays".

In VB.NET the concepts are simplified. Again like Forms, the "hidden"
control vars don't exist anymore. You just have a "real" control var, that
is like any other member variable. If you want an array of them, you create
a new ArrayList and add those control vars to it.

And what about building control arrays dynamically. First of all, for some
strange reason, in VB you need a seed control on the form. Then you need to
learn the wierd Load and Unload statements. In VB.NET you just create a new
instance of a control like any other object, and add it to some array if you
want a control array. Simple and consistant.

Event Handlers
============
What is in VB that makes a function like "Private Button1_Click()" handle
Button1's Click event. Another wierd feature <g>. It magically examines
the function's name and signature, and if it matches, then that handles the
event. Give Button1 an Index property, and suddenly the signature needs to
change.

In VB.NET the concept of an event handler is made more explicit with the
"Handles ControlVar.EventName". This of course is more powerful, but even
as a concept, I suggest that it is easier to learn.

Option Base x
==========
Another wierd VB concept to say good riddance to. Everything is base 0 in
VB.NET. Simple and consistant, and no need for the newbie to learn that a
ListBox items are 0 based, whilst the LiewView items are 1 based.

Option Strict On
============
Evil type coercion is widely regarded as a lesson the newbie learns the hard
way. Good riddance to such magic. It is not a hard concept to learn that a
variable of one type needs to be explicitly converted to another type.

VB Statements
============
Where have they all gone! Most of them are now simply class methods, like
any other class method. For example, given a string var, typing "str." will
prompt intellisense to list all the valid methods along with a nice tooltip
describing what they do. You don't need to scour the help files looking for
global statements that operate on strings, you just examine the string class
to see what it can do. Simple and consistant.

Painting
======
The concept of handling the paint event to do the painting, is not very
difficult to learn in VB.NET. In VB it is just plain wierd. How long did
it take you to work out what the heck AutoRedraw does. I'll admit, I still
need to remind myself whether it should be True or False. And how many
people need to remind themselves of the Line statement syntax, wierd or
what. In VB.NET the Graphics class is easy to use, and intellisense and
tooltips help you all the way. No more "pic.Image = pic.Image" answers to
FAQs.

DF
==
Circular references are just something the newbie has to experience, and the
solutions are either restrictive or complicated hacks beyond the newbie's
reach. The downside of Disposing resources is not a particularly difficult
concept to learn, and newbies will surely get burnt forgetting to call
Dispose as well, but the solution is easy and it makes sense.

Collections
========
How many newbies actually understand how the [_Enum] function allows the For
Each syntax to be used on a collection. In VB.NET the concepts are simple
and consistant, and fall neatly into place with the OO model learnt in the
introductory course. You derive or aggregate one of the collection bases.
By deriving, a collection class requires less code in VB.NET to implement.

ByRef Default
==========
Why oh why was ByRef the default? I am so tired of writing ByVal on 90% of
my params, and this yet again is something that the newbie has to learn to
do. In VB.NET, ByVal being the default is far more sensible especially with
the Strings now being real objects, and the newbie can simply ignore the
concept of ByRef until they need it.

COM
====
Don't think I need to explain this one. ActiveX exe's, binary
compatibility, registration, are just the tip of the iceberg.

ActiveX Controls
=============
A black art in VB, beyond the reach of the newbie. In VB.NET, you're
creating a custom control as soon as you add a new form. The model for
custom controls is again simple and consistant, and inheritance gets the
newbie up and running with a few lines of code.

----------
Well now you know why I couldn't be bothered to list everything <g>. I'm
sure there's a lot more I could think of. The IDE has improved with dynamic
help, the auto-locals pane, cool property sheet, etc.. The loss of the
intermediate window however is a big disadvantage to newbies and experts
alike.

I think there's probably a good argument that the newbie can get a *test*
app up and running in VB slightly faster. But I would argue that it is only
at the expense of picking up bad habits and writing bad code. Those habits
need to be forced out of them, either through experience or a hard-headed
manager. In VB.NET, good habits and a clear understanding are enforced by
the language from day one, and the concepts are simple and consistant enough
that the *full* learning curve to writing production apps is much shorter
IMO.

--
David.

[William Cleveland]

David Bayley wrote:
>
>Forms
>=====
> with a bit of experience you will simply ignore the
> hidden vars altogether.
>
I don't know about that. I'm not sure all of my coworkers even know
that you can deal with a form simply as a type. I've taught that to
at least one or two of them.

> Option Base x
> ==========
> Another wierd VB concept to say good riddance to. Everything is base 0 in
> VB.NET. Simple and consistant, and no need for the newbie to learn that a
> ListBox items are 0 based, whilst the LiewView items are 1 based.
>

I agree wholeheartedly with most of what you've said, but I have to
dispute this one. I don't like the way the array bases were
inconsistent in VB6, but making everything base zero is not the way to
fix it. I would have preferred mandatory explicit top and bottom
bounds.

> DF
> ==
> Circular references are just something the newbie has to experience, and the
> solutions are either restrictive or complicated hacks beyond the newbie's
> reach. The downside of Disposing resources is not a particularly difficult
> concept to learn, and newbies will surely get burnt forgetting to call
> Dispose as well, but the solution is easy and it makes sense.
>
This will be a pain, but thinking back to my QBX experience, in two
years, I only ever had substantial trouble result from forgetting to
close a file once. Usually, I'd write the open line and the close
line at the same time, and then put code in the middle.

I've never run into a circular reference problem, either, but that's
probably just because I hear so many dire warnings about it. I'm
much more interested in the speed gain that it's supposed to give.

> Collections
> ========
> How many newbies actually understand how the [_Enum] function allows the For
> Each syntax to be used on a collection. In VB.NET the concepts are simple
> and consistant, and fall neatly into place with the OO model learnt in the
> introductory course. You derive or aggregate one of the collection bases.
> By deriving, a collection class requires less code in VB.NET to implement.
>

I have to confess, I've been using VB professionally more-or-less full
time for two years, and on-the-job occasionally for another two years
before that, and I still don't understand collections.

> ByRef Default
> ==========
> Why oh why was ByRef the default? I am so tired of writing ByVal on 90% of
> my params, and this yet again is something that the newbie has to learn to
> do. In VB.NET, ByVal being the default is far more sensible especially with
> the Strings now being real objects, and the newbie can simply ignore the
> concept of ByRef until they need it.
>

I'm not contientious enough to remember to actually put in ByVal
everywhere, but I will always put a note in the function header if
I'm actually going to use the fact that a parameter is ByRef. I
do that about a quarter as often as I use GoSub, which is pretty
rare, itself.

Bill

[Jon Ogden]

"David Bayley" <davidb@aebacus.another.spam.filter.com> wrote in message
news:3aa27010@news.devx.com...

> I've been mulling it over, and I would like to put aside whether VB.NET is
> suitable for "beginners" or not, and simply argue that it is easier to
learn
> than VB. i.e. if one accepts that VB is suitable for beginners, then
VB.NET
> is more so.

I think the question is both valid and will have a great deal to do with
whether there is ever a VB2.NET.

However, the proposition that if VB6 is suitable for beginners, then VB.NET
would be even better suited to them seems to go against the common wisdom,
and the experience of many of the people posting in the newsgroup. You seem
to be speaking from the point of view of an experienced, multi-lingual
programmer and assuming that a relative newcomer who has not used one of the
C-type languages will experience VB.NET as you do. This also flies in the
face of many posters perceptions.

Although your step-by-step defense of VB.NET's design choices was cogent
and well-written, it did not address the issue that many of the concepts you
cite as being not-wierd must be learned before an application can be written
in VB.NET. Their counterparts in VB6 can, in most cases be ignored.

Arguing that they _should_ be learned does not lessen the requirement that
they _must_ be. The many things that _must_ be learned before one can fly an
airplane is what makes it hard to learn to fly.

> I think there's probably a good argument that the newbie can get a *test*
> app up and running in VB slightly faster.

Slightly? I would be willing to bet that someone with 8 hours of experience
with VB6 could get a simple application compiled and running more quickly
that most or all of us could get the same application functional in VB.NET,
and I mean no disrespect to anyone frequenting this ng.

As to your use of the word, 'test," isn't that what someone new to VB is
supposed to be writing? I certainly do not think that my division would ever
allow someone to write production code of any sort until they could write
test applications of gradually increasing complexity.

> But I would argue that it is only at the expense of picking up bad habits
and writing bad code.
> <snip> In VB.NET, good habits and a clear understanding are enforced by
> the language from day one, and the concepts are simple and consistant
enough
> that the *full* learning curve to writing production apps is much shorter

Time and again studies on how humans learn show that they do it by moving
from a simplistic and limited model to ones that are gradually less and
less so. A true beginner, required to meet very high standards from day one
is likely to have less interest in learning and be more likely to drop out
either actually or in spirit than one who receives positive reinforcement
for hisher successes, limited and ill-gotten as they might seem to us. Other
theories of learning simply do not hold up when applied to the real world.

> The loss of the
> intermediate window however is a big disadvantage to newbies and experts
> alike.

It's a killer, isn't it?

Good Luck,
Jon

[Dave Keighan]

David, Willian & Jon

Excellent.

Thank-you. Looking forward to more exactly like this! This thread, it's tone
and content are what I read this group for. The slash and burn stuff in
other threads, although entertaining to a certain extent, provides little.

--
Dave Keighan
Everybody Wins If You Post Your Replies to the NG

[Gregor R. Peisker]

Hi David,

I really enjoyed your comments.

> Collections
> ========
> How many newbies actually understand how the [_Enum] function allows the
For
> Each syntax to be used on a collection.

Yes, it beats the heck out of setting the proc ID to negative four. You can
even implement you own enumerator easily.

Regards,
Gregor

[Gregor R. Peisker]

Hi Mark,

the interesting word here is "still". Compared to the Basic language of
'60s, it's not; but of course programming standards have changed. Compared
to VB6? Sure VB6 is different from the old Basic. So was VB6 good for
beginners?

For one, it did too many things behind the scenes that were worth learning
about. Think of event handling, form instantiation, evil type coercion.

Then, it was designed to obfuscate basic programming concepts. VB would have
won any "obfuscated OO tool" contest. For example, controls had a "Name"
property. It really set the name of a Public WithEvents reference variable.
As a consequence, the conceptual difference between an object and a
reference to it is something many didn't learn. That one could set the
"name" of a control in the same way as the name of a class didn't help
either; on the same note, the documentation obfuscated common programming
terms ("the Collection object").

VB6 didn't support console applications, so there was the UI overhead for
the simplest of apps. Heck, VB "Hello, World!" apps were far more
complicated then their C counterparts.

So VB6, while it wasn't a bad tool all in all, was a poor learning tool.
VB.Net has a more consistent programming model, and the learning process is
more steady.

Regards,
Gregor

[Mark Burns]

Jon,
<inline>

"Jon Ogden" <jon@ogdenco.net> wrote in message
news:3aa28245$1@news.devx.com...
>
> "David Bayley" <davidb@aebacus.another.spam.filter.com> wrote in message
> news:3aa27010@news.devx.com...
>
> > I've been mulling it over, and I would like to put aside whether VB.NET
is
> > suitable for "beginners" or not, and simply argue that it is easier to
> learn
> > than VB. i.e. if one accepts that VB is suitable for beginners, then
> VB.NET
> > is more so.
>
> I think the question is both valid and will have a great deal to do with
> whether there is ever a VB2.NET.
>
> However, the proposition that if VB6 is suitable for beginners, then
VB.NET
> would be even better suited to them seems to go against the common wisdom,
> and the experience of many of the people posting in the newsgroup. You
seem
> to be speaking from the point of view of an experienced, multi-lingual
> programmer and assuming that a relative newcomer who has not used one of
the
> C-type languages will experience VB.NET as you do. This also flies in the
> face of many posters perceptions.
>
> Although your step-by-step defense of VB.NET's design choices was cogent
> and well-written, it did not address the issue that many of the concepts
you
> cite as being not-wierd must be learned before an application can be
written
> in VB.NET. Their counterparts in VB6 can, in most cases be ignored.
>
> Arguing that they _should_ be learned does not lessen the requirement that
> they _must_ be. The many things that _must_ be learned before one can fly
an
> airplane is what makes it hard to learn to fly.

*EXACTLY*!
To make a rediculous cartoonish analogy to drive home your point:
VB6/VBClassic is like a roller coaster. It has rails, and you can't move off
them.
However, you are free to reconstruct where the rails go to a pretty
significant degree, so the loss of freedom that the rails represent is not
quite so hard to bear as it first may seem.
By contrast, VB.Net has no rails. It is instead a pair of rocket-powered
rollerblade-like shoes. Now, can you use these shoes to embark on the same
path you were previously travelling along the VB6 coaster? Generally, yes,
you can, but now the rules you must be aware of are completely different
(angular momentum -vs- thrust springs to mind, for starters) and far greater
in number and consquence, and these rules contrast pretty starkly with "keep
your hands and legs inside the coaster car at all times" in terms of
simplicity.

> > I think there's probably a good argument that the newbie can get a
*test*
> > app up and running in VB slightly faster.
>
> Slightly? I would be willing to bet that someone with 8 hours of
experience
> with VB6 could get a simple application compiled and running more quickly
> that most or all of us could get the same application functional in
VB.NET,
> and I mean no disrespect to anyone frequenting this ng.

Again, you nail it here.
Programming isn't supposed to be about how clever we are making Tom Sawyer
paint the fence in patterns we determine, it's supposed to be about making
technology solve (business) problems - in the quickest, best manner we can.
Does have to learn about an object framweork and OOA/OOD rules _really_ help
us solve our problems the most effectivly as often as we think it does? In
your development excperience, how many times have you solved real problems -
and saves hours of effort in the process - by doing something quick & dirty?
<talking past you to David Bayley et. al, here Jon>

> As to your use of the word, 'test," isn't that what someone new to VB is
> supposed to be writing? I certainly do not think that my division would
ever
> allow someone to write production code of any sort until they could write
> test applications of gradually increasing complexity.
>
> > But I would argue that it is only at the expense of picking up bad
habits
> and writing bad code.
> > <snip> In VB.NET, good habits and a clear understanding are enforced by
> > the language from day one, and the concepts are simple and consistant
> enough
> > that the *full* learning curve to writing production apps is much
shorter
>
> Time and again studies on how humans learn show that they do it by moving
> from a simplistic and limited model to ones that are gradually less and
> less so. A true beginner, required to meet very high standards from day
one
> is likely to have less interest in learning and be more likely to drop out
> either actually or in spirit than one who receives positive reinforcement
> for hisher successes, limited and ill-gotten as they might seem to us.
Other
> theories of learning simply do not hold up when applied to the real world.

This is the crux of my argument. Thank You for putting it so eloquently and
succinctly.

> > The loss of the
> > intermediate window however is a big disadvantage to newbies and experts
> > alike.
>
> It's a killer, isn't it?

=(

> Good Luck,
> Jon
>
>

[Mark Burns]

<inline>

"Bob Butler" <butlerbob@earthlink.net> wrote in message
news:3aa25942@news.devx.com...
>
> "Mark Burns" <mark@iolofpa.com> wrote in message
> news:3aa1c683@news.devx.com...
> > The above is a question I have been (instinctively?) holding the answer
> out
> > to be an emphatic: NO!
> > I have even been going so far as to state that BASIC is no longer the
> > appropriate name for this new language, which Microsoft is calling
Visual
> > Basic.Net, preferring instead the shortened acronym Visual ASIC.Net as
> being
> > more correct for this new language.
> >
>
> Working with a local VB user's group, hanging out in various VB newsgroups
> and fielding a lot of VB/VBA questions at work I've dealt with a pretty
> broad cross-section of VB developers. If you'll pardon the broad
> generalizations I tend to see four different kinds of VB beginners:
>
> A: they have used one or more other languages (C++, Delphi, Java, any
> language that deals with objects) for a while on actual production code
but
> are new to VB and need or want to pick up VB for work

This makes them non-newbies. VB Rookies, perhaps, but not newbies as their
brains already have the programming/logical thought construct pathways in
place.

> B: they are new to programming in general and have mostly academic
> experience, if that, and are starting out as a programmer in a VB
> environment (could also be people with experience in non-object-based
> languages)

Ok, this would be a mix of newbies and rookies, then.

> C: they are non-programmers who want to use VBA or who want to be able to
> slap together something functional for themselves for their work

definitely newbies.

> D: they are hobbyists who enjoy playing around with programming

Highly likely to be newbies, but may be rookies, depending on the background
and experience...

> When I look at VB.Net in comparison to VB6 my guess at the reactions is:
>
> A: VB.Net is not bad; some pros, some cons, but overall the existing
> experience and techniques can be moved into the VB.Net world pretty
easily.

I can agree with that - generally, although, YMMV, of course.

> B: If the developer "gets" objects and how to design and use them then
> VB.Net will look good; if not, it will be a confusing mess of rules
learned
> by rote and applied poorly

Yup. With the added caveat that the ones who "get" objects in this category
will almost certainly be put back to square one in learning the new
framework and particular rules, and while they do that, no useful code
(other than "test" code) is likely to come from them for some time (YMMV).

> C: VB.Net is likely to be very daunting and if they use it at all they
will
> barely scratch the surface; most may stay VB6 or find some alternative

Yup. No Beginners need apply.<g>

> D: VB.Net will be too daunting and they'll move to something else

Probably Yup again.

> The strength I have always seen in VB has been that it was accessible to
> those millions while still allowing experienced developers to create and
> maintain good software quickly. It traded some power and performance for
> simplicity and that was a reasonable tradeoff IMO. In trying to explain
VB6
> to new developers the main obstacle has always been getting them to fully
> understand and implement objects. The upside was that you could still
> create usable code in VB6 without a real understanding but I don't see the
> same for VB.Net. I think VB.Net raises the bar too high for most of the
> category C and D people and even possibly for many of the category B
people.
> I think that's a loss to the VB community.

Precisely, I think your analysis is spot on, generally.