Is VB.Not still a BEGINNERS' language?

[Joe \Nuke Me Xemu\ Foster]

"Mark Burns" <mark@iolofpa.com> wrote in message <news:3aa2b736@news.devx.com>...

> Jon,
> <inline>

> > 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.

So VB.NOT slaps us right back to Smalltalk, in which it seems you must
first eat, drink, and breathe the entire class library before you can
put up so much as a "hello world" window? VB6 doesn't force anything
on anyone that VB1 didn't, allowing newbies to start with dipping a toe
into the shallow end and gradually wade in over their heads. =) VB.NOT
does NOT have a "shallow end" of the pool?

--
Joe Foster <mailto:jfoster@ricochet.net> Greed = God? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Joe \Nuke Me Xemu\ Foster]

"Mike Mitchell" <kylix_is@hotmail.com> wrote in message <news:3aa2339c.4042769@news.devx.com>...

> 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.

Ask any military officer what usually happens when a plan meets reality.

--
Joe Foster <mailto:jfoster@ricochet.net> Greed = God? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[David Bayley]

Jon,

> 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.

I think it is difficult for everybody here (me included, and VB *is* my
primary tool), to put themselves back in the position of learning VB from
scratch. Certainly there are lots of people who think VB.NET is more
difficult, but I don't agree that it is common wisdom. And even if it was,
then common wisdom would be wrong IMO <g>.

> 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.

If you look at the points I raised, they consisted of concepts that _don't_
have to be learnt. Sure there are lots of things that need to be learnt in
*both* VB and VB.NET. My argument is that by using one consistant OO model,
it is _easier_ to learn them.

> 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.

Why? I need some concrete examples. The newbie creates a new project with
a blank form, drag-&-drops a button and textbox on to it, double-clicks the
button and writes some event handling code. This is what makes VB so easy,
and VB.NET is just as easy in this respect. The only thing that is
"slightly" harder, is the template form code includes some other "stuff".

The Form Generated code however is a useful learning tool, and actually
_improves_ the learning curve. I imagine that the newbie will find it
extremely helpful to use the designer to create a form and set some
properties, then examine the auto-generated code to see how it should be
done at run-time.

> 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.

I'm still not convinced that the test app is significantly harder. The key
metric however, is how difficult it is to get to a production app. The
point at which a test app is possible is merely a psychological feel good
factor.

> 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.

I agree. But the end goal is to be able to write production apps (I'm not
talking about a high standard or complicated app, just real-world working
apps). There is no point making it easy to write a test app, if it means
adopting bad habits that need to be scrapped and re-learnt to reach the end
goal and pass the final exam. Small steps can still be taken... i.e. Step
1: open a new project, drag-&-drop a few controls, and write some simple
event handling code.

--
David.

[David Bayley]

Mark,

> 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?

OOA/OOD no... that is only useful when you have a complex problem domain.
But an object framework most definitely helps! The object frameworks
introduced in MS Office are a clear example. I for one, found those a huge
boost in productivity and ease-of-learning, and I know a number of
non-programmers (who wouldn't have touched the old macros) that have
benefited from them too. Again, it is the simple and consistant model that
is the key enabler here.

> 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>

You can still do the quick & dirty. I need concrete examples of why that
isn't possible in VB.NET.

> > 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...
>
> This is the crux of my argument. Thank You for putting it so eloquently
and
> succinctly.

I'll raise the same point that I made to Jon. What is it exactly that is so
hard in VB.NET, to make those first tentative steps compared to VB
(analagies are not allowed <g>)? i.e. open a project, drag-&-drop some
controls, and double-click them to write some simple event handling code.

--
David.

[Mike Mitchell]

On Sun, 4 Mar 2001 20:07:24 +0100, "Gregor R. Peisker"
<gregor@peisker.de> wrote:

>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.

All you need to do is show a beginner a small-ish app written in VB6,
and then the equivalent code written in VB.NET. I think you'll find
that most, if not all, beginners will choose the "classic" VB method.

However, many have been saying that VB.NET is really a "BASIC" version
of C#, and who would claim C# is less difficult than VB6? So, if VB6
is, say, 10 points on the "easy" scale and C# is 5 points, then VB.NET
must be somewhere between C# and VB6, say, around 7. Ergo, even on the
simplest of scales VB6 *is* an easier language for beginners to pick
up and run with.

Here's an example using arrays: In VB6, you tell the beginner, (s)he
can create a list of items in memory, i.e. an array. You explain that
the list can start anywhere, even a negative number, and finish
anywhere. If you have temperatures that go from 32 to 212, you can
create a corresponding array.

Now you tell the beginner about VB.NET arrays and that they must
always start from zero. If the beginner is a true beginner, you'll
have to get over the stumbling block we all had once about the magic
of counting from zero, which none of us does naturally. To the
beginner, starting from zero simply will not appear to be as simple as
starting from 32. To the beginner, his array will, in his head,
continue to start from 32, as conceptually that is his first value.
So, in his head, and later in code, he will have to continually
translate between 32 and zero.

Therefore, for most, if not all, beginners, classic VB arrays will be
simpler to grasp and use, hence VB.NET will not be seen as easier to
learn. Also observe that a language, to be easier, has to be easier in
every aspect. If only one facet of a language is easier, but all other
facets are more difficult, then that language must overall be harder.
For example, compare a cycle ride over flat terrain with a similar
cycle ride that has a dip in the middle. Most riders will initially
look forward to the freewheeling down into the dip, but not relish the
thought of pedalling up the other side. But on reflection, the flat
path is always the easiest overall, as it is the shortest to reach the
destination, plus on the flat path you can always see what lies ahead
and anticipate where you're going next, whereas you never know what
may be awaiting you in the dip, though by the time you reach it, it's
too late to do anything about it - you're committed anyway.

MM

[Gregor R. Peisker]

Hi Mike,

> All you need to do is show a beginner a small-ish app written in VB6,
> and then the equivalent code written in VB.NET. I think you'll find
> that most, if not all, beginners will choose the "classic" VB method.

I'm not sure if the overall method (or what do they call it, the
"paradigm"?) is all that different. God (or whoever, depending on how this
metaphor is localized) is in the details. Also, classic VB has been arround
for a long time, so it's more familiar.

> However, many have been saying that VB.NET is really a "BASIC" version
> of C#, and who would claim C# is less difficult than VB6? So, if VB6
> is, say, 10 points on the "easy" scale and C# is 5 points, then VB.NET
> must be somewhere between C# and VB6, say, around 7. Ergo, even on the
> simplest of scales VB6 *is* an easier language for beginners to pick
> up and run with.

I'd say Basic is easier than C because of its straightforward, make-sense
syntax, and other language features. I know many people think classic VB's
forms designer really was the killer, but not me. As for C#, it's closer in
terms of ease than C++, but that's not the point. Anyway, the ratings really
depend on what you do - just show the beginner the code for using
SHBrowseForFolder in classic VB, and compare that to the new FolderBrowser
class.

> Here's an example using arrays: In VB6, you tell the beginner, (s)he
> can create a list of items in memory, i.e. an array. You explain that
> the list can start anywhere, even a negative number, and finish
> anywhere. If you have temperatures that go from 32 to 212, you can
> create a corresponding array.

Yes. I could make a fool out of myself and claim that arrays are actually an
advanced feature. But I don't. Now, actually most people would say the new
way is easier, and in fact, there is some value in having consistency. But I
think user-defined bounds aren't hard to understand to begin with, and you
get a lot of usability from them. To say that the butchering of this feature
makes the tool easier to use is foolish, because that implies users are real
dullards, but I wouldn't go that far in definding my claim that VB.Net is
easy.

You've got a point here.

> Also observe that a language, to be easier, has to be easier in
> every aspect. If only one facet of a language is easier, but all other
> facets are more difficult, then that language must overall be harder.
> For example, compare a cycle ride over flat terrain with a similar
> cycle ride that has a dip in the middle. Most riders will initially
> look forward to the freewheeling down into the dip, but not relish the
> thought of pedalling up the other side. But on reflection, the flat
> path is always the easiest overall, as it is the shortest to reach the
> destination, plus on the flat path you can always see what lies ahead
> and anticipate where you're going next, whereas you never know what
> may be awaiting you in the dip, though by the time you reach it, it's
> too late to do anything about it - you're committed anyway.

My impression is that, with classic VB you rode over flat terrain for some
time, and then you had to ditch the bike altogether, because it was too
heave to carry with you on the free climb up the rock that lay before you.
VB.Net, on the other hand, is like a slightly uphill ride, but the can stay
on your bike.

> MM

Regards,
Gregor

[Wally McClure]

yes and no is the answer.

yes it is a beginners language because it's syntax is still realitvely
simple when compared to C Sharp, Java, and other languages.

no because there are many more advanced concepts in the product. While
begineers do not need to use items, such as threading, the concepts are
clearly beyond a beginner's skillsets.

Wally

"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.
>
> 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...
>
>

[Frustrated IT Worker]

Maybe, some of the developers who are actually writing tests applications
in VB.NET would like to chime in on this discussion?

I think it all depends on how you are using the programming language. What
I mean is that after reading a 1997 article by Scott Ambler (and a more recent
one as well from the author's web site) on the difficulties of mapping objects
to relational databases, I question whether a newbie would have sufficient
knowledge to create a relatively simple database application in VB.NET. With
classic VB the resources available to this type of programmer are vast.

I doubt that most CS graduates have even written a business application in
Java or C++ while in school. Over the last two years, I have browsed through
numerous Java books and only a handful discussed business application development
issues.

[Jon Ogden]

David, thanks for the careful and thought provoking reply. I've edited some
of what you said, only for bandwidth.
"David Bayley"

> I think it is difficult for everybody here (me included, and VB *is* my
> primary tool), to put themselves back in the position of learning VB from
> scratch. Certainly there are lots of people who think VB.NET is more
> difficult, but I don't agree that it is common wisdom. And even if it
was,
> then common wisdom would be wrong IMO <g>.

Well, common wisdom is often wrong, but methinks that in here we have
uncommon wisdom.

For my sins I have been asked to shepherd a number of experienced cobol
programmers through the intricacies of VB6. For me, therefore, this thread
is not academic, nor is it as difficult for me to understand and speak to
the process of learning the language.

> If you look at the points I raised, they consisted of concepts that
_don't_
> have to be learnt. Sure there are lots of things that need to be learnt
in
> *both* VB and VB.NET. My argument is that by using one consistant OO
model,
> it is _easier_ to learn them.

I certainly agree that there are lots of things that need be learned in
both, but all numbers greater than 50 are not equal to each other. The
learning curve to get to hello-world is steeper in .NET.
On the other hand, your clarification means I now think that you are
pointing out that since VB has been "rationalized" in .NET, there are far
fewer gotchas waiting to be memorized. In that sense, a programmer is freed,
once heshe climbs happy mountain to focus on the job. And I agree.

> > 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.
>
> Why? I need some concrete examples. The newbie creates a new project
with
> a blank form, drag-&-drops a button and textbox on to it, double-clicks
the
> button and writes some event handling code.

Actually, I was thinking of a working app - one I use in my first class:
blank form > dbgrid > adocontrol > set a few properties > run. _No_
code.
(The coballers look at me as if I have just pulled an elephant out of a
tophat -- and so I have. I also go on to point out just how *&^%*ing
dangerous doing that would be except on a test database on a test server in
a test mode.)

>This is what makes VB so easy,
> and VB.NET is just as easy in this respect. The only thing that is
> "slightly" harder, is the template form code includes some other "stuff".
> <snip> I imagine that the newbie will find it
> extremely helpful to use the designer to create a form and set some
> properties, then examine the auto-generated code to see how it should be
> done at run-time.

Why do you imagine that? When you learn to drive, it is _always_ easier to
learn on an automatic than a standard shift car.

> > 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.
>
> I'm still not convinced that the test app is significantly harder. The
key
> metric however, is how difficult it is to get to a production app. The
> point at which a test app is possible is merely a psychological feel good
> factor.

Psychological feel-good factors are the primary tool in assisting someone to
learn. If you think of them as "merely," you are making a mistake. ****,
even when I was a DI in the army, we used strokes to get the trainees where
they needed to be.

> > 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.
>
> I agree. But the end goal is to be able to write production apps (I'm not
> talking about a high standard or complicated app, just real-world working
> apps).

Of course that's the ultimate goal and we are discussing the best method of
getting to the point where one can learn to write production code. This
thread capitalizes "Beginners" in its subject, does it not? Early learning
is as different from late learning as early binding is from late. <grin>

There is no point making it easy to write a test app, if it means
> adopting bad habits that need to be scrapped and re-learnt to reach the
end
> goal and pass the final exam.

Bad habits are learned and forgotten every day. To tell you the truth, I
think this is a chimera that has been used to put down VB from the day it
was invented. It was also applied to automatic transmissions, power steering
and power brakes, iirc. It may have originally been applied to wagons - "If
you cover the **** things, sonny, you gonna larn yerself all sorts of bad
habits. You won't see the Indians coming, until it's too late!"

I've _seldom_ met a reasonably intelligent programmer who is not constantly
looking for ways to do things better. For instance, I learned to fish using
a bamboo pole that had fishingline tied to the end of it. Such a simple
beginning did not preclude my learning the intricacies of fly-fishing, nor
keep me from recognizing the benefits of doing so. (Sorry for all the
similes. I am being snowed in as I write and it may be affecting my mind.)

> Small steps can still be taken... i.e. Step
> 1: open a new project, drag-&-drop a few controls, and write some simple
> event handling code.

I didn't say it was impossible - I just said it was harder....for instance,
as you pointed out yesterday, if there's an error in that "simple event
handling code" - you won't be able to edit and continue. To some extent,
this looms so large in the early learning process, that I'm not sure that
everything else we have talked about matters in comparison.

Good Luck!

[Jon Ogden]

"Joe "Nuke Me Xemu" Foster"

> Ask any military officer what usually happens when a plan meets reality.

I was an NCO, I'd offer my opinion, but I think DEVX wouldn't allow it to
remain. <grin>

[Glen Miille]

Well in my experience, everytime a plan met with reality they tried to use a
crowbar on reality to make it fit the plan!

Glen

"Jon Ogden" <jon@ogdenco.net> wrote in message
news:3aa3b192$1@news.devx.com...
>
> "Joe "Nuke Me Xemu" Foster"
>
> > Ask any military officer what usually happens when a plan meets reality.
>
> I was an NCO, I'd offer my opinion, but I think DEVX wouldn't allow it to
> remain. <grin>
>
>
>

[rmeklo]

with classic VB you rode over flat terrain for some
>time
90% was easy

then you had to ditch the bike altogether
the other 10% you were on your own

>VB.Net on the other hand, is like a slightly uphill ride
80% easy, the other 20% you can work out through extending the framework.

I've run at the (VB) wall often, I hope your analogy holds as well for VB.Net
as I think it does for Delphi.

[Mark Burns]

"Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> wrote in message
news:3aa2c540@news.devx.com...
> "Mark Burns" <mark@iolofpa.com> wrote in message
<news:3aa2b736@news.devx.com>...
>
> So VB.NOT slaps us right back to Smalltalk, in which it seems you must
> first eat, drink, and breathe the entire class library before you can
> put up so much as a "hello world" window? VB6 doesn't force anything
> on anyone that VB1 didn't, allowing newbies to start with dipping a toe
> into the shallow end and gradually wade in over their heads. =) VB.NOT
> does NOT have a "shallow end" of the pool?

I think that is far closer to reality than should make any experienced VB
Developer, or, for that matter, anyone at MS who wears a "VB.Net Development
Team" Logo on their shirts, very comfortable at all.

[Mark Burns]

"Jon Ogden" <jon@ogdenco.net> wrote in message
news:3aa3af34$1@news.devx.com...
> David, thanks for the careful and thought provoking reply. I've edited
some
> of what you said, only for bandwidth.
> "David Bayley"
>
> For my sins<?> I have been asked to shepherd a number of experienced cobol
> programmers through the intricacies of VB6.

<guffaw> What'd you do? "Sleep with" three different Boss' Wives, Daughters
& Mothers? ...in the same day? ...on their desks? ...with the
intercom/speakerphone on?!<g>

> For me, therefore, this thread
> is not academic, nor is it as difficult for me to understand and speak to
> the process of learning the language.
>
> > If you look at the points I raised, they consisted of concepts that
> _don't_
> > have to be learnt. Sure there are lots of things that need to be learnt
> in
> > *both* VB and VB.NET. My argument is that by using one consistant OO
> model,
> > it is _easier_ to learn them.
>
> I certainly agree that there are lots of things that need be learned in
> both, but all numbers greater than 50 are not equal to each other.

Word up.

>The learning curve to get to hello-world is steeper in .NET.

Precisely the problem, and it matters not if we're talking about BobB's A,
B, C, or D-type programmers. That hill must be climbed _first_, and no
matter what the GUI does do for/with you, there is just no getting around
that point.

> On the other hand, your clarification means I now think that you are
> pointing out that since VB has been "rationalized" in .NET, there are far
> fewer gotchas waiting to be memorized. In that sense, a programmer is
freed,
> once heshe climbs happy mountain to focus on the job. And I agree.

...as do I. I think we're all basically saying the same thing here, and if
there's to be any real argument left in this topic, I guess it is: is that
initial learning curve an anthill, molehill, gentle rolling appalachian
hill, or a Rockies/Everest? ...to which there can be no single, simple
grand-unifying answer.

> Actually, I was thinking of a working app - one I use in my first class:
> blank form > dbgrid > adocontrol > set a few properties > run. _No_
> code.
> (The coballers look at me as if I have just pulled an elephant out of a
> tophat -- and so I have. I also go on to point out just how *&^%*ing
> dangerous doing that would be except on a test database on a test server
in
> a test mode.)

Do you also point out how USEFUL that can be for those frequent/occasional
<YMMV> one-off "fix this database now" problem resolutions?

> >This is what makes VB so easy,
> > and VB.NET is just as easy in this respect. The only thing that is
> > "slightly" harder, is the template form code includes some other
"stuff".
> > <snip> I imagine that the newbie will find it
> > extremely helpful to use the designer to create a form and set some
> > properties, then examine the auto-generated code to see how it should be
> > done at run-time.
>
> Why do you imagine that? When you learn to drive, it is _always_ easier
to
> learn on an automatic than a standard shift car.

....but that analogy fails because in order to drive either you need no
understand much about internal combustion engines. Here, in VB.Net, how far
can you get without understanding MyBase, which leads directly to
understanding subclassing...hardly a beginner's topic in any programming
language coursework I've ever heard of.

> Psychological feel-good factors are the primary tool in assisting someone
to
> learn. If you think of them as "merely," you are making a mistake. ****,
> even when I was a DI in the army, we used strokes to get the trainees
where
> they needed to be.

You were a DI? Aww...Man, I pity those poor Cobol-ers you have at your
mercy!
"MOVE 3 to X?? WHAT DO YOU THINK THIS IS? COBOL or VB?? DROP AND GIVE ME
TWENTY!!!"<g>

> Of course that's the ultimate goal and we are discussing the best method
of
> getting to the point where one can learn to write production code. This
> thread capitalizes "Beginners" in its subject, does it not? Early
learning
> is as different from late learning as early binding is from late. <grin>

Good catch! ;-)

> Bad habits are learned and forgotten every day. To tell you the truth, I
> think this is a chimera that has been used to put down VB from the day it
> was invented. It was also applied to automatic transmissions, power
steering
> and power brakes, iirc. It may have originally been applied to wagons -
"If
> you cover the **** things, sonny, you gonna larn yerself all sorts of bad
> habits. You won't see the Indians coming, until it's too late!"

Also, as the rules change over time, what was once "standard practice"
becomes a "bad habit", so worrying overmuch about learning bad habits cal
leave you just chasing your tails endlessly - and useful code it the goal,
right? <anybody remember the days of coding in BASIC with two-letter
variable names & type-suffuxes?>

> (Sorry for all the similes. I am being snowed in as I write and it may be
> affecting my mind.)

heh...s'Ok...blame me for spreading the similie contageon.<g>

> > Small steps can still be taken... i.e. Step
> > 1: open a new project, drag-&-drop a few controls, and write some
simple
> > event handling code.
>
> I didn't say it was impossible - I just said it was harder....for
instance,
> as you pointed out yesterday, if there's an error in that "simple event
> handling code" - you won't be able to edit and continue. To some extent,
> this looms so large in the early learning process, that I'm not sure that
> everything else we have talked about matters in comparison.

Yup! =(

[Joe \Nuke Me Xemu\ Foster]

"rmeklo" <rbmeklo@MEDIAONE.NET> wrote in message <news:3aa3cd9d$1@news.devx.com>...

> with classic VB you rode over flat terrain for some
> >time
> 90% was easy
>
> then you had to ditch the bike altogether
> the other 10% you were on your own

Google to the rescue?

> >VB.Net on the other hand, is like a slightly uphill ride
> 80% easy, the other 20% you can work out through extending the framework.
>
> I've run at the (VB) wall often, I hope your analogy holds as well for VB.Net
> as I think it does for Delphi.

Which VB walls have you not yet broken?

--
Joe Foster <mailto:jfoster@ricochet.net> Space Cooties! <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!