"Robert Morley" <rmorley> wrote in message
news:4592
> Wasn't that cited in the original VB.NET as being the reason that some
> features couldn't be maintained? I seem to remember it was, though I
> won't claim certainty on that.

If that was the case I would say it was BS on MSs part. They made the IL so
they could make it any way they wanted.

> Really? Access hasn't had to break backwards compatibility
> since...well...ever, yet it performs fantastically for a local database,
> and continues to add features with each release.

Access is one of the most horrible applications I've ver used. It's
completely unstable and extremely outdated. If something badly needs a
complete update it's Access. A complete break from the past could
potentially make a top app and really revolutionise internal apps.

> All the other Office apps are pretty much the same.

The office API is pretty horrible also.

> The Windows API hasn't broken compatibility (significantly, anyway) across
> all 32-bit versions, and has compatibility layers for 16-bit versions (and
> of course the 64-to-32 bit layer in the 64-bit versions).

They have no choice there.

> But looking strictly at languages, C++ hasn't had any major breakage since
> dinosaurs roamed the Earth,

And it's still stuck in the dinosaur age.

> nor has Delphi,

I haven't used delphi that much

> or HTML,

HTML is horribly outdated also. SQLServer is a good example also, it's been
compatible for many years but is really stuck in the dark ages. No table
inheritance and the stored proc syntax is a disaster.

> or...I'm sure if I thought about it, I could go on for a while. So why is
> VB "special"?

I don't know but now they've done it they've created something truly
special. It's the first language I know of that has no skeletons from the
past. It's extremely refreshing. They have compatibility with outdated
technology such as COM but it has been implemented very well and isn't
holding it back in any way. To make it compile VB6 syntax as is would have
held it back a *HUGE* amount.

> But let's say there were significant gains to be made by breaking
> compatibility, you'll never convince me that things like forcing all
> arrays to start with the same base was a *necessary* compatibility break
> in order to make VB.NET "better" somehow.

You don't strictly need to have zero based arrays, there is a way around it
I believe. I have never used it though as I don't see the need and do think
the consistancy is better. I don't see any reason to start a list of items
at anything besides zero.

> I suppose you might argue that it lends to more structured programming,

Yes :-)

> but if that were a concern in VB, there would've been a lot of other
> things removed or altered as well. They may also have wanted to consider
> the concept that if they were going to break compatibility, they should
> have designed the new language in such a way that an upgrade could
> actually do a half-decent job instead of just littering code with ToDo
> statements.

I agree they most definately should have done a better job there. A lot of
the problems would be caused by upgrading to ADO.net, if plain old ADO was
used it would probably be a lot easier.

I'm suprised a third party hasn't released a better upgrade tool. It
wouldn't be hard to do and would be popular and could be fairly expensive.

Michael

"Robert Morley" <rmorley> wrote in message
news:4592
>
> Really? Access hasn't had to break backwards compatibility
> since...well...ever, yet it performs fantastically for a local database, and
> continues to add features with each release. All the other Office apps are
> pretty much the same. The Windows API hasn't broken compatibility
> (significantly, anyway) across all 32-bit versions, and has compatibility
> layers for 16-bit versions (and of course the 64-to-32 bit layer in the 64-bit
> versions). But looking strictly at languages, C++ hasn't had any major
> breakage since dinosaurs roamed the Earth, nor has Delphi, or HTML, or...I'm
> sure if I thought about it, I could go on for a while. So why is VB
> "special"?
>

Actually VB6/VBA is special. It is the one language that is entirely COM based -
forms, text boxes, variants, ADODB, the whole thing. It is what made VB such an
effective tool, since you could do so many COM-based things in a straightforward
way, and still use the entire windows API at the same time. That is why there
are/were so many 3rd-party components available for VB6.

If you take out of VB6/VBA everything that is COM based, you are left with just
about nothing. That is not true for C++ and other systems. While you can use
COM-interop in a .Net program, there would be no point in doing that with the
VB6 code itself - you would be passing every line through a COM-interop layer
wrapped around the VB6 runtime. Far better to leave the code in VB6, if you want
it to run as is.

I myself do not think that MS said to themselves, "lets break VB". What they did
is create .Net, a complete replacement for COM. Since VB6 is so utterly COM
dependent, their choices were to have no VBish-style tool for programming .Net,
or to create VB.Net/Fred. If they had chosen option A, there would have been
plenty of howling about not having any .Net version of VB. They chose option B.

"Robert Morley" <rmorley> wrote in message
news:4592
>
> But let's say there were significant gains to be made by breaking
> compatibility, you'll never convince me that things like forcing all arrays to
> start with the same base was a *necessary* compatibility break in order to
> make VB.NET "better" somehow.

It is worth repeating that .Net was not setup with VB in mind - it is a single
model for all the languages that use it. If C and Java are also at the party, it
is not unreasonable to decide to use 0 based arrays. It is what all arrays
actually are under the hood anyway. If you make an array in VB from 2 To 5, the
actual storage is still 0 based, the index just has to be translated every time
you use the array. There is really no harm in making a an array 0 To 5, then
only using the indexes 1 To 5.

"Steve Gerrard" <mynamehere> wrote in message
news:nz2d
> It is worth repeating that .Net was not setup with VB in mind - it is a
> single model for all the languages that use it. If C and Java are also at
> the party, it is not unreasonable to decide to use 0 based arrays. It is
> what all arrays actually are under the hood anyway. If you make an array
> in VB from 2 To 5, the actual storage is still 0 based, the index just has
> to be translated every time you use the array. There is really no harm in
> making a an array 0 To 5, then only using the indexes 1 To 5.

There is some harm in the fact that bugs are not so easily found as you
don't get an error when referencing what should be an illegal index (zero).

"Steve Gerrard" <mynamehere> wrote in message
news:nz2d
> I myself do not think that MS said to themselves, "lets break VB". What
> they did is create .Net, a complete replacement for COM. Since VB6 is so
> utterly COM dependent, their choices were to have no VBish-style tool for
> programming .Net, or to create VB.Net/Fred. If they had chosen option A,
> there would have been plenty of howling about not having any .Net version
> of VB. They chose option B.

Changing the underlying platform from COM-based to .Net-based is not
justification for the language syntax changes that were made though. Things
like changing Label1.Caption to Label1.Text, removing Gosub/Return, and
renaming the enumeration constants (to take just a few simple examples) were
simply gratuitous. When a VB coder writes "Text1.BackColor = vbRed" he
doesn't care whether it uses COM, the win32 API or voodoo as long as the
result is a red textbox on the screen. Even the issue of zero-based arrays
could have been handled in .Net (perhaps with a performance penalty but
telling me that my code will move forward and run but I may want to rewrite
to get better performance would have been 1000% better than the current
situation).

There are a few things that may not have been feasible to implement but MS
then looked at it and said
since we can't do everything let's not worry about doing anything". The
attitude was, and still is, that VB is a toy language suitable only for
throw-away work. Anybody trusting them by moving to VB.Net is being
extremely naive.

"Michael C" <nospam> wrote in message
> I don't know but now they've done it they've created something truly
> special. It's the first language I know of that has no skeletons from the
> past. It's extremely refreshing.

In which case they should have given it a different name.

I don't think many people are saying that the "Visual Basic" .NET is
intrinsically bad, just that it not the natural successor to VB6 and to
promote it as such is dishonest and cynical.

Dave O.

I really think this is the most relevant point. As I've written in the past,
VB.Net is about the most stupid name Microsoft could've given the language.
I like C#, and I like VB.Net -- but the VB.Net name both trivializes the
changes and most likely dooms the language. I like VB6 also, but as someone
in here always writes, "whatever VB.Net is, it sure aint VB". With that I
agree.

"Dave O." <nobody> wrote in message
news:3872
[..]

> Access is one of the most horrible applications I've ver used. It's
> completely unstable and extremely outdated. If something badly needs a
> complete update it's Access. A complete break from the past could
> potentially make a top app and really revolutionise internal apps.

You're the first person I've ever heard of who actually dislikes Access...at
least to that extent. What do you see as wrong with it?

>> The Windows API hasn't broken compatibility (significantly, anyway)
>> across all 32-bit versions, and has compatibility layers for 16-bit
>> versions (and of course the 64-to-32 bit layer in the 64-bit versions).
>
> They have no choice there.

Oh but they do...they could choose to go the same route they did with VB.NET
and break compatibility with all former applications, forcing all existing
code to be re-written. But that would be a dumb idea, wouldn't it? ;-)

>> But looking strictly at languages, C++ hasn't had any major breakage
>> since dinosaurs roamed the Earth,
>
> And it's still stuck in the dinosaur age.

Okay, I suppose I can't argue with that. :-)

> HTML is horribly outdated also. SQLServer is a good example also, it's
> been compatible for many years but is really stuck in the dark ages. No
> table inheritance and the stored proc syntax is a disaster.

What do you mean by table inheritance? I think I know (Access supported a
highly limited version of it), but just want to be clear.

> I don't know but now they've done it they've created something truly
> special. It's the first language I know of that has no skeletons from the
> past. It's extremely refreshing. They have compatibility with outdated
> technology such as COM but it has been implemented very well and isn't
> holding it back in any way. To make it compile VB6 syntax as is would have
> held it back a *HUGE* amount.

That's fair enough. In point of fact, I like at least some of the things
they've done with the language, but they seriously needed to provide SOME
path forward without having to re-write nearly everything from scratch.

> You don't strictly need to have zero based arrays, there is a way around
> it I believe.

So I've heard. I believe there was some class or some such that implemented
it for you, and I gather that recently, there's been some kind of linguistic
work around that's been discovered, but I don't know the details. It's
still rather limiting that the language doesn't support it natively.

> I have never used it though as I don't see the need and do think the
> consistancy is better. I don't see any reason to start a list of items at
> anything besides zero.

An array of days of the month comes to mind right off hand. Why number it 0
to 30 when it could be 1 to 31?

> I agree they most definately should have done a better job there. A lot of
> the problems would be caused by upgrading to ADO.net, if plain old ADO was
> used it would probably be a lot easier.

Hey, we agree on something! Hehehe.

> I'm suprised a third party hasn't released a better upgrade tool. It
> wouldn't be hard to do and would be popular and could be fairly expensive.

Yes, it would be EXTREMELY popular, I'd imagine.


Rob

> doesn't care whether it uses COM, the win32 API or voodoo

Oh, oh! I want one that uses voodoo! Then there'd be all kinds of
justification for those techies who make their machines work like magic.



Rob

"Robert Morley" <rmorley> wrote in message
news:3460
>> doesn't care whether it uses COM, the win32 API or voodoo
>
> Oh, oh! I want one that uses voodoo! Then there'd be all kinds of
> justification for those techies who make their machines work like magic.
>>
> Rob

hmmm... works fine here <g>

Option Base 1 at the general decs level will force arrays to start at 1.

================================
Option Base

Used at module level to declare the default lower bound for array
subscripts.

Syntax

Option Base {0 | 1}

Remarks

Because the default base is 0, the Option Base statement is never required.
If used, the statement must appear in a module before any procedures. Option
Base can appear only once in a module and must precede array declarations
that include dimensions.

Note The To clause in the Dim, Private, Public, ReDim, and Static
statements provides a more flexible way to control the range of an array's
subscripts. However, if you don't explicitly set the lower bound with a To
clause, you can use Option Base to change the default lower bound to 1. The
base of an array created with the the ParamArray keyword is zero; Option
Base does not affect ParamArray (or the Array function, when qualified with
the name of its type library, for example VBA.Array).

The Option Base statement only affects the lower bound of arrays in the
module where the statement is located.



|
| So I've heard. I believe there was some class or some such that
implemented
| it for you, and I gather that recently, there's been some kind of
linguistic
| work around that's been discovered, but I don't know the details. It's
| still rather limiting that the language doesn't support it natively.

"Robert Morley" <rmorley> wrote in message
news:3460
>> doesn't care whether it uses COM, the win32 API or voodoo
>
> Oh, oh! I want one that uses voodoo! Then there'd be all kinds of
> justification for those techies who make their machines work like magic.

Chicken.Waive(WaveAround.Head,WaiveTime.Midnight)

"Robert Morley" <rmorley> schrieb im Newsbeitrag
news:3460

> Oh, oh! I want one that uses voodoo! Then there'd be all
> kinds of justification for those techies who make their machines
> work like magic.

But, as the Game Cat says,
BE CAREFUL, BE VERY CAREFUL.
THIS RIDE IS NOT FOR THE WEAK.

;-)

Olaf

"Robert Morley" <rmorley> wrote in message
news:2452
>> Access is one of the most horrible applications I've ver used. It's
>> completely unstable and extremely outdated. If something badly needs a
>> complete update it's Access. A complete break from the past could
>> potentially make a top app and really revolutionise internal apps.
>
> You're the first person I've ever heard of who actually dislikes
> Access...at least to that extent. What do you see as wrong with it?

I'm definately not the first person. The problems are extensive but
basically you're not making a real app. With VB6 you have to work to add the
required functionality. In access you have to work to remove a lot of
functionality in an attempt to make it look like a real app. The forms just
look plain ugly and outdated because they made all their own controls. This
also eliminates the possibility of using APIs on the controls because they
are not real windows controls. Then there's the instability of the backend
and problems with customers having different versions.

> Oh but they do...they could choose to go the same route they did with
> VB.NET and break compatibility with all former applications, forcing all
> existing code to be re-written. But that would be a dumb idea, wouldn't
> it? ;-)

They could not do that and you know it. It is a different situation to what
has happened with dot net and your analogy doesn't quite hold water. With
VB6 you can still develop apps in vb6 that will run on all OSs. A better
analogy would be if they implemented a new API structure in windows but kept
the old one also, which is exactly what they do all the time.

> What do you mean by table inheritance? I think I know (Access supported a
> highly limited version of it), but just want to be clear.

I should be able to create a table called Person with FirstName, LastName
etc and then create Staff and Customer tables that inherit from Person. I
haven't ever used it so not sure how well it would work in reality.

> That's fair enough. In point of fact, I like at least some of the things
> they've done with the language, but they seriously needed to provide SOME
> path forward without having to re-write nearly everything from scratch.

I agree. The upgrade wizard is something they gave to a junior programmer on
his first day.

> So I've heard. I believe there was some class or some such that
> implemented it for you, and I gather that recently, there's been some kind
> of linguistic work around that's been discovered, but I don't know the
> details. It's still rather limiting that the language doesn't support it
> natively.

Have a read of this one, it looks like they tried to have non-zero based
arrays but decided against it for very good reason.
http://www.panopticoncentral.net/arc...03/17/290.aspx

> An array of days of the month comes to mind right off hand. Why number it
> 0 to 30 when it could be 1 to 31?

I would prefer 1 based arrays myself but am more than happy to have all zero
based arrays if that means we have consistancy. I agree it's a little
confusing going from 0 to 30 but this is the same with any list of items.
The first item is index zero, the second is index 1 etc.

>> I'm suprised a third party hasn't released a better upgrade tool. It
>> wouldn't be hard to do and would be popular and could be fairly
>> expensive.
>
> Yes, it would be EXTREMELY popular, I'd imagine.

Could be a good project for those on this group.

Michael

Bob Butler <noway> wrote:
> simply gratuitous. When a VB coder writes "Text1.BackColor = vbRed" he
> doesn't care whether it uses COM, the win32 API or voodoo as long as the
> result is a red textbox on the screen.

Bingo! That _is_ the fundamental definition of a HLL.

Separation of programmer from the underlying platform.

This betrays the true motive which was platform lockin.