Re: VB 7 Wish List

[Jim Pragit]

Yes, I've had this problem as well. What makes it slightly annoying is that
there is extra space in the dialog that's not being used (at least on my
screen). I sent Microsoft an e-mail about this a while back.

- Jim

"Eric Litwin" <eric_litwin@countrywide.com> wrote:
>
>>2. The Project References. Can't see enough entries.
>
>My biggest problem with this dialog is that the "Location" displayed when
>selected a reference is often cut off. I sometimes have complex directory
>structures and I cannot see if a reference is being made to a .VBP (when
>working with a group) or a compiled .DLL. Very annoying.
>

[- John of Arc -]

To continue with my petty desires:

-self-referencing types (a type that can have a member of its same type)
that can be used in data structures (in addition to classes)

-distinct assignment and equality operators, and
-assignment operations, yeah, and more, returning the value of the 'right
hand side' (e.g. a line of code like if ((dog="poodle")=="poodle") then
would result in the string "poodle" being assigned to the variable dog,
which would equal the string literal "poodle", so the whole expression would
return TRUE . . .

-the "insert/procedure" builder allow the specification of return types for
functions and properties - now that would save some anying time-wasting

-all datatypes having a boolean FALSE and TRUE (and that remain more-or-less
a number, unlike Java's foolish non-numeric boolean type) , e.g. Empty,
NULL, Nothing, vbnullchar, vbnullstring, 0, etc. would all return false in
an IF or Cbool() test.

-related to the above, a little pointer arithmetic would be nice, especially
in places like looping until the end of a string or array is encountered . .

-C/Java 'shortcut' syntax, e.g. n+=4.

-increment and decrement operators (at least the syntax, if not any
performance increase), i.e., i++, i--, ++i, --i

-a "this" reference inside a function (especially those that serve as
constructors by being declared of a specific type) that refers to the object
in question in the current scope - similar to "Me" in a class, but
different - a syntactical shortcut to avoid having to declare return buffer
variable of the same type or having to type the name of a function over and
over again as you operate on it (if you choose to work this way)


-handy editor functions like those you find in any decent text editor - a
useful right-click context menu, etc.

[Colin McGuigan]

- John of Arc - wrote in message <38cefe4e@news.devx.com>...
>To continue with my petty desires:
>
>-self-referencing types (a type that can have a member of its same type)
>that can be used in data structures (in addition to classes)

You can have this now; you just can't have it immediately instantiate this
member (for the obvious reason that if you do, you'll quickly enter an
infinite loop of creating objects). However, that doesn't stop you from
having a member that isn't created until it's Property Get is accessed, etc.

>-distinct assignment and equality operators, and
>-assignment operations, yeah, and more, returning the value of the 'right
>hand side' (e.g. a line of code like if ((dog="poodle")=="poodle") then
>would result in the string "poodle" being assigned to the variable dog,
>which would equal the string literal "poodle", so the whole expression
would
>return TRUE . . .

I'd like it to (as well as taking the + away from string concatenation), but
I don't think it'll happen, because it'd break almost every piece of code
ever made.

>-the "insert/procedure" builder allow the specification of return types for
>functions and properties - now that would save some anying time-wasting
>
>-all datatypes having a boolean FALSE and TRUE (and that remain
more-or-less
>a number, unlike Java's foolish non-numeric boolean type) , e.g. Empty,
>NULL, Nothing, vbnullchar, vbnullstring, 0, etc. would all return false in
>an IF or Cbool() test.

I don't agree with Null (since it indicates, by definition, something
neither true nor false). As for the rest, you could write your own function
(CBoolEx?) that could handle all of these.

>-related to the above, a little pointer arithmetic would be nice,
especially
>in places like looping until the end of a string or array is encountered .
..

The ability to access characters in a string directly, rather than having to
use Mid().... I don't think you'll see anything of the sort, though.

>-C/Java 'shortcut' syntax, e.g. n+=4.

Why? Assuming that the compiler optimizes 'n += 4' and 'n = n + 4' to the
same machine code, I'd rather people use the latter sequence, as it's more
obviously understandable.

>-increment and decrement operators (at least the syntax, if not any
>performance increase), i.e., i++, i--, ++i, --i

Again, why? I can see the use in C/Java's for() loops, but VB doesn't use
that syntax anyway.

>-a "this" reference inside a function (especially those that serve as
>constructors by being declared of a specific type) that refers to the
object
>in question in the current scope - similar to "Me" in a class, but
>different - a syntactical shortcut to avoid having to declare return buffer
>variable of the same type or having to type the name of a function over and
>over again as you operate on it (if you choose to work this way)

I'm not seeing a difference between 'this' and 'Me'; could you provide a
short code example?

>-handy editor functions like those you find in any decent text editor - a
>useful right-click context menu, etc.

--
Colin McGuigan

[- John of Arc -]

The term is arbitrary, I guess (and comes from other languages).

"Me" is currently used inside a class definition to refer to itself.

I'd like to be able to do the same in a function so that I don't have to
know the function's name, especially where the function is defined to return
an object (and is therefore a constructor). In other words, in a function
defined to return an instance of MyNiftyClass, inside the function as it is
setting up the instance's properties, perhaps calling a few of its methods,
etc., it can self-refer using "This" or perhaps a re-use of "Me".

For, example, a boolean function:

Set This=False

Or one returning a recordset:


Set This=...openRecordset(...)

Or a collection:

set This=new collection

with this
.add(...)
.add(...)
end with


To add to my wishlist:

-the ability to pass the address of callback procedures defined in
classes to API functions






> >-a "this" reference inside a function (especially those that serve as
> >constructors by being declared of a specific type) that refers to the
> object
> >in question in the current scope - similar to "Me" in a class, but
> >different - a syntactical shortcut to avoid having to declare return
buffer
> >variable of the same type or having to type the name of a function over
and
> >over again as you operate on it (if you choose to work this way)
>
> I'm not seeing a difference between 'this' and 'Me'; could you provide a
> short code example?
>
> >-handy editor functions like those you find in any decent text editor - a
> >useful right-click context menu, etc.
>
> --
> Colin McGuigan
>
>
>

[- John of Arc -]

Dear Santa,

-the VB IDE as a VBScript editor:
-vbscript in web pages
- vbscript in the windows scripting host (in .wsc and .ws XML files as
well as .vbs files)
-html pages with scripts in them, WSH scripts, and HTAs as a types of
project templates available in VB

[Mark Hurd]

"Colin McGuigan" <colin@chicor.com> wrote in message
news:38cfac3f@news.devx.com...
> - John of Arc - wrote in message <38cefe4e@news.devx.com>...
> >To continue with my petty desires:
> >
> >-self-referencing types (a type that can have a member of its same type)
> >that can be used in data structures (in addition to classes)
>
> You can have this now; you just can't have it immediately instantiate this
> member (for the obvious reason that if you do, you'll quickly enter an
> infinite loop of creating objects). However, that doesn't stop you from
> having a member that isn't created until it's Property Get is accessed,
etc.

I think JoA feels a bit bothered by having to create a whole new module for
the node of a simply linked list. I know I do.

>
> >-distinct assignment and equality operators, and

I see no confusion here, except for what you then suggest...

> >-assignment operations, yeah, and more, returning the value of the 'right
> >hand side' (e.g. a line of code like if ((dog="poodle")=="poodle") then
> >would result in the string "poodle" being assigned to the variable dog,
> >which would equal the string literal "poodle", so the whole expression
> would
> >return TRUE . . .

As a person who uses VB like C, I'd like to be able to do this, but I don't
see it as a high priority.

>
> I'd like it to (as well as taking the + away from string concatenation),
but
> I don't think it'll happen, because it'd break almost every piece of code
> ever made.

Yes. The only way to work around this would be to have a new assignment
operator, say ;=...

>
> >-the "insert/procedure" builder allow the specification of return types
for
> >functions and properties - now that would save some anying time-wasting

I'd prefer they fixed the IDE object model so that we could then write this
AddIn ourselves easily.

> >-related to the above, a little pointer arithmetic would be nice,
> especially
> >in places like looping until the end of a string or array is encountered
..
> .
>
> The ability to access characters in a string directly, rather than having
to
> use Mid().... I don't think you'll see anything of the sort, though.

Mid$("",x,1) would compile to be almost identical to ""(x), as available in
C, if the compliler could compile Mid$ 'inline'...

> >-C/Java 'shortcut' syntax, e.g. n+=4.

Yes!

>
> Why? Assuming that the compiler optimizes 'n += 4' and 'n = n + 4' to the
> same machine code, I'd rather people use the latter sequence, as it's more
> obviously understandable.

Sorry, n += 4 is more readable to me, as i am not new to the syntax. (I'm
all for maintainable code, but I'd expect my code to be maintained by
someone with at least a year's experience :-} )

Also in the VB scenario, suppose you actually said:

frmFoo.objBar.value += 56

This should compile to the equivalient of:

With frmFoo.objBar

.value = .value + 56

End With

and it should still then be able to optimise lower level stuff we can't see
at the VB level.

The reason why this is a great optimisation is hidden in using With above:

frmFoo.objBar.value = frmFoo.objBar.value + 56

actually has to cater for the possibility that the property get of value, or
objBar, modifies the reference objBar, so that the value that is modified is
not the one corresponding to the value that is retrieved. Yes, I know you'd
be a fool to deliberately design code like that, but it is somewhat feasable
in Windows that this sort of scenario is actually quite common. (I'm
thinking of windows styles that can only be set when the window is created,
and this being wrapped in a object that destroys and creates windows as
required, etc.)

>
> >-increment and decrement operators (at least the syntax, if not any
> >performance increase), i.e., i++, i--, ++i, --i
>
> Again, why? I can see the use in C/Java's for() loops, but VB doesn't use
> that syntax anyway.

See above. You imply we are only looking for typing savers. I don't mind if
they are called Increment and Decrement (actually to be more VB-like I'd
suggest Inc and Dec), and like I said above about the assignment operator,
++ and += don't have to return a value if that causes too many troubles...

>
> >-a "this" reference inside a function (especially those that serve as
> >constructors by being declared of a specific type) that refers to the
> object
> >in question in the current scope - similar to "Me" in a class, but
> >different - a syntactical shortcut to avoid having to declare return
buffer
> >variable of the same type or having to type the name of a function over
and
> >over again as you operate on it (if you choose to work this way)

Based upon your wording here, you seem to describe a this similar to my
understanding of the C++ this. Even if this is not what you meant, I'd like
it:

In a module, when a class, or a form or usercontrol, calls a routine, Me
is not defined in the module code. I think it should still be. I presume it
would have to be implemented the same way I could implement an approximation
to it now: you have a hidden private module variable Me As Object and just
before every reference to the module by a class execute "Set mod.Me = Me".
There are *lots* of problems that I can see from this implementation that
ought to extend to most implementations. I don't see it being done.

>
> I'm not seeing a difference between 'this' and 'Me'; could you provide a
> short code example?

Based upon JoA's response to this, this does just seem to be a typing saver.

However, I see it as a good idea. Effectively, this is a synonym for the
variable that is the name of the function. Its usefulness is that you can
change the function name without having to change any code within it, unless
it is recursive.

>
> >-handy editor functions like those you find in any decent text editor - a
> >useful right-click context menu, etc.

We have that? The useful context menu that is...

I'd like the IntelliSense code to work in comments -- only on demand
(ctrl+space), of course.

>
> --
> Colin McGuigan

--
Mark Hurd, B.Sc.(Ma.)(Hons.)
Director of Software Engineering
Netline Technologies International Ltd

[Audie F. Thomas]

Changing the behavior of the assignment / equality operator is a terrible
idea!
If you started with C it might seem desireable, but as someone who started
with
Basic and now also uses C, I can tell you that accidentally using assignment
when I want equality is one of my most common C programming errors.

[Vlad Ivanov]

>> >-increment and decrement operators (at least the syntax, if
>> >performance increase), i.e., i++, i--, ++i, --i
>>
>See above. You imply we are only looking for typing savers. I don't mind
if
>they are called Increment and Decrement (actually to be more VB-like I'd
>suggest Inc and Dec), and like I said above about the assignment operator,
>++ and += don't have to return a value if that causes too many troubles...

Just as a side observation, we shouldn't really ask for more complex syntax.
VB is not meant to be hardwired typing efficient Morse code like C++ is.
Symbolical syntax like ! (instead of Not), &&, ||, ++ etc... they maybe save
your typing here but do not contribute to the language ease of use. Normal
words should be used. Some extra typing doesn't really hurt THAT much.

Most readable code (and that won't break existing) is Inc and Dec like you
offered. How about using Delphi syntax here:

Inc(VarToIncrement, optional Increment)
Dec(VarToDecrement, optional Decrement)

So to increment by 1 you go Inc(MyVar). To increment by 56 you go Inc(MyVar,56).

Like it?

>
>>
>> >-a "this" reference inside a function (especially those that serve as
>> >constructors by being declared of a specific type) that refers to the
>> object
>> >in question in the current scope - similar to "Me" in a class, but
>> >different - a syntactical shortcut to avoid having to declare return
>buffer

Again, nicely solved by Delphi's Result keyword.

Function MySub() as Long
Dim lValue as Long =1
'''Alow me to use our new friend initializer here

Result=lValue
''' Do whatever after this. Result is basically a
''' result buffer. It doesn't affect execution path.

End sub

BTW, in addition, pointer would be useful in VB no matter what. Most importantly
fucntion pointers. And with all the OOP additions VB ought to have RTTI features
(run-time type info) that would allow to query an object to find out what
type it is, what is it a descendant from etc...

[Jason Bock]

"Vlad Ivanov" <vivanov@polarisconsulting.com> wrote in message
news:38da6646$1@news.devx.com...
> Most readable code (and that won't break existing) is Inc and Dec like you
> offered. How about using Delphi syntax here:
>
> Inc(VarToIncrement, optional Increment)
> Dec(VarToDecrement, optional Decrement)
>
> So to increment by 1 you go Inc(MyVar). To increment by 56 you go
Inc(MyVar,56).
>
> Like it?

Personally, I do. I don't mind typing

i++

or

i += 5

but then it's starting to "look like" C++/Java. Not that it matters much,
but I think it's more readable to have:

Incr(x)

and

Incr(x, 5)

Saves typing as well. Either way, I hope this is added!

Regards,

Jason

[Jon]

"Vlad Ivanov" <vivanov@polarisconsulting.com> wrote:
>
>>> >-increment and decrement operators (at least the syntax, if
>>> >performance increase), i.e., i++, i--, ++i, --i
>>>
>>See above. You imply we are only looking for typing savers. I don't mind
>if
>>they are called Increment and Decrement (actually to be more VB-like I'd
>>suggest Inc and Dec), and like I said above about the assignment operator,
>>++ and += don't have to return a value if that causes too many troubles...
>
>Just as a side observation, we shouldn't really ask for more complex syntax.
>VB is not meant to be hardwired typing efficient Morse code like C++ is.
>Symbolical syntax like ! (instead of Not), &&, ||, ++ etc... they maybe
save
>your typing here but do not contribute to the language ease of use. Normal
>words should be used. Some extra typing doesn't really hurt THAT much.

OTOH, there's certainly an argument for saying that C (and C++ out-of-the-box)
do things the Right Way - i.e. they don't overload operators with two semantically
different meanings. After all, x = 5 (assignment) is semantically *very*
different from x = 5 (equality). C, C++, Pascal etc all mandate that these
two be expressed differently (C/C++ has x=5/x==5, Pascal has x:=5/x=5) which
is, IMHO, A Good Thing.

Similarly C's operator & has very different semantics to operator && (7 &&
5 returns true, 7 & 5 returns 7) yet all Basics overload both meanings onto
the And operator.

>Most readable code (and that won't break existing) is Inc and Dec like you
>offered. How about using Delphi syntax here:
>
>Inc(VarToIncrement, optional Increment)
>Dec(VarToDecrement, optional Decrement)
>
>So to increment by 1 you go Inc(MyVar). To increment by 56 you go Inc(MyVar,56).
>
>Like it?
>
>>
>>>
>>> >-a "this" reference inside a function (especially those that serve as
>>> >constructors by being declared of a specific type) that refers to the
>>> object
>>> >in question in the current scope - similar to "Me" in a class, but
>>> >different - a syntactical shortcut to avoid having to declare return
>>buffer
>
>Again, nicely solved by Delphi's Result keyword.
>
>Function MySub() as Long
> Dim lValue as Long =1
>'''Alow me to use our new friend initializer here
>
> Result=lValue
> ''' Do whatever after this. Result is basically a
> ''' result buffer. It doesn't affect execution path.
>
>End sub
>
>BTW, in addition, pointer would be useful in VB no matter what. Most importantly
>fucntion pointers. And with all the OOP additions VB ought to have RTTI
features
>(run-time type info) that would allow to query an object to find out what
>type it is, what is it a descendant from etc...

RTTI's nice but expensive, and works a lot better with inheritance than with
aggregation: I'd be suprised to see it in 7 because it'd be *very* difficult
to retrofit into the language (i.e. if my class has faked inheritance through
a combination of interface aggregation and delegation, what sort of useful
RTTI is available to its clients)

Proper block comments would be nice, though, and, nicer still:

<rant>
A SLOW AND PAINFUL DEATH FOR THE ****ING MODAL DIALOG BOX WHICH APPEARS WHEN
YOU CURSOR OFF AN UNCOMPLETED LINE. I *know* there's an error in my code
or it doesn't make any sense: it's because I haven't finished writing it.
Sure, mark the line as red, but that *doesn't* get in my way: opening up
the relevant help page *does*.
</rant>

[Rodney Willis]

>
>Proper block comments would be nice, though, and, nicer still:
>
><rant>
>A SLOW AND PAINFUL DEATH FOR THE ****ING MODAL DIALOG BOX WHICH APPEARS
WHEN
>YOU CURSOR OFF AN UNCOMPLETED LINE. I *know* there's an error in my code
>or it doesn't make any sense: it's because I haven't finished writing it.
>Sure, mark the line as red, but that *doesn't* get in my way: opening up
>the relevant help page *does*.
></rant>

You know you can turn that dialog box off by going to
Tools->Options and unchecking the Auto-Syntax Check. You still get the red
line for the error, but no annoying dialog box!

[Pierre Blanchette]

"Jason Bock" <jrbock@execpc.com> wrote:
>"Vlad Ivanov" <vivanov@polarisconsulting.com> wrote in message
>news:38da6646$1@news.devx.com...
>> Most readable code (and that won't break existing) is Inc and Dec like
you
>> offered. How about using Delphi syntax here:
>>
>> Inc(VarToIncrement, optional Increment)
>> Dec(VarToDecrement, optional Decrement)
>>
>> So to increment by 1 you go Inc(MyVar). To increment by 56 you go
>Inc(MyVar,56).
>>
>> Like it?
>
>Personally, I do. I don't mind typing
>
>i++
>
>or
>
>i += 5
>
>but then it's starting to "look like" C++/Java. Not that it matters much,
>but I think it's more readable to have:
>
>Incr(x)
>
>and
>
>Incr(x, 5)
>
>Saves typing as well. Either way, I hope this is added!
>
>Regards,
>
>Jason
>

I agree, VB is *NOT* C and should not be polluted by those who think C has
a neat syntax. In fact it is really poor from the readability point of view.
In the late 70's I was an APL support specialist and I liked it but I never
thought of suggesting that the COBOL should implement some APL syntax!

Too bad this pollution is already started (ex: Iif)

So please leave VB as it is, an easy to use easy to read language with less
performance but more productivity than C

Pierre

[Robert]

>>>suggest Inc and Dec),
Better to be Incr and Decr so that people don't look at Dec and think it
has somthing to do with Decimal.

[Mark Hurd]

"Jon" <jon@datasim.co.uk> wrote in message news:38db5769$1@news.devx.com...
<snip>
>
> OTOH, there's certainly an argument for saying that C (and C++
out-of-the-box)
> do things the Right Way - i.e. they don't overload operators with two
semantically
> different meanings. After all, x = 5 (assignment) is semantically *very*
> different from x = 5 (equality). C, C++, Pascal etc all mandate that these
> two be expressed differently (C/C++ has x=5/x==5, Pascal has x:=5/x=5)
which
> is, IMHO, A Good Thing.

However, in VB, and Pascal, the assignment statement is contextually
different to the equality operator. (I'm implying that Pascal would still be
compilable if it had = instead of := for assignment. It is a while since
I've had to know the language that well, so don't flame me if I've forgotten
the big feature that defeats this.)

VB gets away with a simpler syntax because the context is always
determinable. I don't agree with 'expressing differently' the two normal
meanings of =, unless we also get the assignment expression concept as an
added feature.

>
> Similarly C's operator & has very different semantics to operator && (7 &&
> 5 returns true, 7 & 5 returns 7) yet all Basics overload both meanings
onto
> the And operator.

Remember that in C, True = 1 and in BASIC True = -1. Now the only difference
between & and && is that && converts its inputs to 1 if they are not 0, and
short-circuiting, which is where this thread started...

And is now overloaded in VB, because there is a Boolean type, but when there
wasn't, (and if you use integers 0 and -1, not True and False now) x And y =
x & y and it was a 'side-effect' that if x and y were only ever 0 or -1, you
got boolean algebra.

In other words, And is exactly equivalent to &, Or with |, and if you use
only boolean values (0 and +/-1) you can interchange & and && and | and ||
and get the same result, except that short-circuiting causes fewer
evaluations.

> >Most readable code (and that won't break existing) is Inc and Dec like
you
> >offered. How about using Delphi syntax here:
> >
> >Inc(VarToIncrement, optional Increment)
> >Dec(VarToDecrement, optional Decrement)
> >
> >So to increment by 1 you go Inc(MyVar). To increment by 56 you go
Inc(MyVar,56).
> >
> >Like it?

'tis OK.

> >>> >-a "this" reference inside a function (especially those that serve as
> >>> >constructors by being declared of a specific type) that refers to the
> >>> object
> >>> >in question in the current scope - similar to "Me" in a class, but
> >>> >different - a syntactical shortcut to avoid having to declare return
> >>buffer
> >
> >Again, nicely solved by Delphi's Result keyword.
> >
> >Function MySub() as Long
> > Dim lValue as Long =1
> >'''Alow me to use our new friend initializer here
> >
> > Result=lValue
> > ''' Do whatever after this. Result is basically a
> > ''' result buffer. It doesn't affect execution path.
> >
> >End sub

Result is what most existing code would already use, Then MySub = Result, as
this avoids the seemingly recursive use of MySub.

> >BTW, in addition, pointer would be useful in VB no matter what. Most
importantly
> >fucntion pointers. And with all the OOP additions VB ought to have RTTI
> features
> >(run-time type info) that would allow to query an object to find out what
> >type it is, what is it a descendant from etc...
>
> RTTI's nice but expensive, and works a lot better with inheritance than
with
> aggregation: I'd be suprised to see it in 7 because it'd be *very*
difficult
> to retrofit into the language (i.e. if my class has faked inheritance
through
> a combination of interface aggregation and delegation, what sort of useful
> RTTI is available to its clients)

No comment, except, how does TypeName$() work and does it help in the above
situation?

>
> Proper block comments would be nice, though, and, nicer still:

Yes, but not a high priority. Columns of ' are OK. Especially if they gave a
control code to the block comment toolbar button by default.

>
> <rant>
> A SLOW AND PAINFUL DEATH FOR THE ****ING MODAL DIALOG BOX WHICH APPEARS
WHEN
> YOU CURSOR OFF AN UNCOMPLETED LINE. I *know* there's an error in my code
> or it doesn't make any sense: it's because I haven't finished writing it.
> Sure, mark the line as red, but that *doesn't* get in my way: opening up
> the relevant help page *does*.
> </rant>

I hope you know that you can disable this by turning off "Automatic Syntax
Checking".

My first change to the IDE of VB and VBA defaults is to turn this off
(leaving just red lines, no fscking dialogue box) and turn on "Require
Variable Declaration". They are normally on the same options page.

I'd like the compiler to be able to attempt to continue past the first
error, at least when run from the command line.
--
Mark Hurd, B.Sc.(Ma.)(Hons.)
Director of Software Engineering
Netline Technologies International Ltd

[- John of Arc -]

Audie F. Thomas <audietech@erols.com> wrote in message
news:38da2551@news.devx.com...
> Changing the behavior of the assignment / equality operator is a terrible
> idea!
> If you started with C it might seem desireable, but as someone who started
> with
> Basic and now also uses C, I can tell you that accidentally using
assignment
> when I want equality is one of my most common C programming errors.

That's exactly why they should be different.
The problem changing them is two-fold however:

-backwards-compatibility with code - it would be a **** of an exercise to
change , with a decent search facility - VB should have a wizard to upgrade,
if so

-it does veer away from traditional BASIC stylistically, which may irk the
purist. Though Visual Basic has historically had to assimilate other
non-basic functionalities to be very useful - Delphi, C, the API, com,
objects, database connectivity, etc., now, VB is its own thing.
Unfortunately, you pay with basic beginner syntax with a lack of power
though Q and QuickBasic had some advanced features dropped in VB. The story
of VB's evolution into a useful language has been one of becoming more and
more like other products, so far C and Delphi - sounds like the next
evolution will mock Java.