array declarations in VB.NET

[Bill McCarthy]

Hi all,

thought it must be my turn to start a thread here <g>

In VB.NET, the proposed syntax for declaring arrays as it appears it is
goint to be is :

Dim a(Ubound) [as Type]

In VB5/6 it is

Dim a([lBound To] UBound) [as Type]

and in other languages such as C# they declare the number of elements as is
the case with Beta1.

I like the fact MS has decided to ensure compatibility with VB5/6, but the
Dim a(UBound) style I don't think is clear to everyone. I can see some may
confuse it with other languages and think it actually means Dim
a(number_of_elements).

What I would like to see is the IDE use it's smarts features, and
automatically update the syntax to the full VB5/6 syntax.

IOW:

I could type in "Dim a(x)" and the IDE would autoamtically change that to:
Dim a(0 To x)

I think that would make the code clear, remove any possible confussion and
also provide compatibility with VB5/6 skills and code.


Thoughts ??

[Larry Serflaten]

"Bill McCarthy" <bill_mcc@iprimus.com.au> wrote

> What I would like to see is the IDE use it's smarts features, and
> automatically update the syntax to the full VB5/6 syntax.
>
> IOW:
>
> I could type in "Dim a(x)" and the IDE would autoamtically change that to:
> Dim a(0 To x)
>
> I think that would make the code clear, remove any possible confussion and
> also provide compatibility with VB5/6 skills and code.

I thought they had to remove the To keyword (hearsay) but if at all possible
I would rather name both bounds and have no questions, than to name only
the upper bound. Of course if the To keyword was brought back into use,
it would most likely be an option, as it was before. But, if not, if it had to
be one way or the other, I would prefer naming both bounds as it was
already supported, and usually decribed as a 'best practices' technique.

LFS

LFS

[Bob Butler]

"Bill McCarthy" <bill_mcc@iprimus.com.au> wrote in message
news:3acffbf0@news.devx.com...
<cut>
> I like the fact MS has decided to ensure compatibility with VB5/6, but the
> Dim a(UBound) style I don't think is clear to everyone. I can see some may
> confuse it with other languages and think it actually means Dim
> a(number_of_elements).

I agree but the argument goes both ways. When I pick up some C code after
working with VB for a while I sometimes read the array declarations as
a(upperbound). No matter which VB.Net uses the single value syntax is going
to cause some confusion. I prefer the "upperbound" in this case only
because going between VB and C is usually enough of a mental shift to make
the confusion minimal while going between VB.Net and VB legacy code it'll be
harder to make the distinction.

> What I would like to see is the IDE use it's smarts features, and
> automatically update the syntax to the full VB5/6 syntax.
>
> IOW:
>
> I could type in "Dim a(x)" and the IDE would automatically change that to:
> Dim a(0 To x)
>
> I think that would make the code clear, remove any possible confussion and
> also provide compatibility with VB5/6 skills and code.

I like that idea. I'd definitely at least like the "0 To" to be optional
even if no other lower bound was allowed so I can keep the same style I use
now -- all arrays are declared with lower and upper bounds explicitly.
There is no doubt when you see "Dim a(0 to 9)" that you have a 10-element
array ending at 9.

[Craig Clearman]

Hi Bill,

>I could type in "Dim a(x)" and the IDE would autoamtically change that to:
> Dim a(0 To x)

Of course I agree. What's more, I can't imagine why it isn't being
done. One of the things that most frustrates me with the changes in
Visual Fred is how some of them break what is considered to be *best
practices.*

Ciao, Craig

[Jonathan Allen]

> I could type in "Dim a(x)" and the IDE would autoamtically change that to:
> Dim a(0 To x)
>
> I think that would make the code clear, remove any possible confussion and
> also provide compatibility with VB5/6 skills and code.


I could care less about compatibility, but I agree on the grounds that it
makes it more intuitive. The only way that "X = Upperbound" makes sense to
me is if there is a lower bound.

--
Jonathan Allen


"Bill McCarthy" <bill_mcc@iprimus.com.au> wrote in message
news:3acffbf0@news.devx.com...
> Hi all,
>
> thought it must be my turn to start a thread here <g>
>
> In VB.NET, the proposed syntax for declaring arrays as it appears it is
> goint to be is :
>
> Dim a(Ubound) [as Type]
>
> In VB5/6 it is
>
> Dim a([lBound To] UBound) [as Type]
>
> and in other languages such as C# they declare the number of elements as
is
> the case with Beta1.
>
> I like the fact MS has decided to ensure compatibility with VB5/6, but the
> Dim a(UBound) style I don't think is clear to everyone. I can see some may
> confuse it with other languages and think it actually means Dim
> a(number_of_elements).
>
> What I would like to see is the IDE use it's smarts features, and
> automatically update the syntax to the full VB5/6 syntax.
>
> IOW:
>
> I could type in "Dim a(x)" and the IDE would autoamtically change that to:
> Dim a(0 To x)
>
> I think that would make the code clear, remove any possible confussion and
> also provide compatibility with VB5/6 skills and code.
>
>
> Thoughts ??
>
>
>
>
>
>

[Harvey Triana]

" This changes will all be implemented in the Visual Studio.NET Beta 2:

*Declaring Arrays: For consistency with other languages, Microsoft
intended to change the way VB declared arrays, so that you would
specify the number of elements in the array: Dim a(10) As Integer would
create a ten-element array, with an upper bound of 9. This conflicts
with the VB style of declaring arrays, where Dim a(10) As Integer
creates an eleven-element array with an upper bound of 10. The
traditional declaration technique has been restored. "

So,
* To my I liked how BETA1 operates the arrays in VB.NET.
* In any case, I think that VB.NET would have to maintain the "TO"
- The old code as Dim X(n1 TO n2) will be a serious problem.
________________________________
Harvey Triana... psoft@latino.net.co
Microsoft Developer MVP- Visual Basic
www.eidos.es/VeXPERT

"Bill McCarthy" <bill_mcc@iprimus.com.au> escribió en el mensaje
news:3acffbf0@news.devx.com...
> Hi all,
>
> thought it must be my turn to start a thread here <g>
>
> In VB.NET, the proposed syntax for declaring arrays as it appears it is
> goint to be is :
>
> Dim a(Ubound) [as Type]
>
> In VB5/6 it is
>
> Dim a([lBound To] UBound) [as Type]
>
> and in other languages such as C# they declare the number of elements as
is
> the case with Beta1.
>
> I like the fact MS has decided to ensure compatibility with VB5/6, but the
> Dim a(UBound) style I don't think is clear to everyone. I can see some may
> confuse it with other languages and think it actually means Dim
> a(number_of_elements).
>
> What I would like to see is the IDE use it's smarts features, and
> automatically update the syntax to the full VB5/6 syntax.
>
> IOW:
>
> I could type in "Dim a(x)" and the IDE would autoamtically change that to:
> Dim a(0 To x)
>
> I think that would make the code clear, remove any possible confussion and
> also provide compatibility with VB5/6 skills and code.
>
>
> Thoughts ??
>
>
>
>
>
>

[Russell Jones]

I'm against the rollback changes altogether. I liked the Beta method of
stating the number of elements better than the older VB upperbound syntax. I
think Dim A(1), meaning A has 1 element, is much clearer than Dim A(0),
meaning A has one element. It's easier to teach, easier to read, and is more
compatible with other languages. I'm well aware that this breaks
compatibility with earlier versions. However, if the rollback to classic VB
upper bound declaration moves forward, I think that it's a necessity to
either require the "0 to X" syntax explicitly or for the IDE to expand the
syntax by adding the "to" keyword so that when you write Dim A(10), the IDE
changes it to Dim A(0 to 9), and I would want that syntax enforced across
all .NET languages.

There are two "compatibility" concerns in VB.NET. Not only the compatibility
of VB.NET with earlier versions of VB, but also syntax compatibility with
other .NET languages. I suspect there will be considerable programmer
movement between languages as companies decide which "flavor" of .NET they
want to support--or decide to support multiple flavors. In addition, because
the .NET languages are already so similar, technical publishers will be
forced to publish articles, tips, and code in multiple .NET languages rather
than maintaining separate per-language publications as they do now. In other
words, there's not enough profit in technical publishing to sustain separate
..NET magazines and Web sites for every possible language flavor. Therefore,
anything that makes it easier for VB.NET programmers to read code in other
languages (and vice versa) will be very important for disseminating
information. While the proposed changes may not affect VB.NET interop at the
binary level, they most definitely will impact cross-language code
readability at the source level.

Frankly, I don't much care if Microsoft forces VB programmers to be
consistent with the rest of the world or if Microsoft goes the other way and
forces the rest of the world to accept the VB syntax. In other words, I
don't have any problem with the rollback changes themselves, and I'd support
them completely if Microsoft also changes other .NET languages to match.
Barring that, I'm against the changes. I want basics--like Array bounds
declarations, and the numeric value chosen for True to be consistent across
all .NET languages.

In general, I think consistency with other languages is a valid argument
against making any of the rollback changes announced for VB.NET. Aren't you
tired of having to learn C syntax to read the documentation for API calls?
How much harder would it have been for you to get started with VB.NET if the
C# examples (and remember, most of the examples were/are/(will be?) in C#)
had had different array bounds syntax than VB.NET? Worse, how much harder
will it be if languages other than VB.NET change the basic assumptions?
Changing the syntax will make it harder for VB.NET beginners to assimilate
code examples in other languages, and (assuming that VB.NET is the only
language that will be different--admittedly an unfounded assumption) will
make VB.NET a less palatable choice for people moving between .NET
languages. Remember, there are likely to be a lot more languages than just
the three we have now. There will be code published in those languages that
you may want to use.

Here's a scenario. You find a perfect code example on NetSolutions.com that
solves a problem for you, but the language used is X-ACT.NET. You need to
translate the code to VB.NET. The code contains an obvious array
declaration, e.g. declare Int32 Array(10). However, without cross-language
declaration consistency the meaning is ambiguous. In pre-rollback .NET, you
would know that there are 10 elements in the array, but in post-rollback
..NET, you're going to have to research the X-ACT.NET array declaration
syntax. It might have 10 or 11 elements--you can't be sure. In contrast, if
the "to" syntax is required for all .NET languages, then you can be
absolutely certain how many elements the array has--even if, sometime in the
future--.NET supports a lower bound for arrays other than 0.


"Harvey Triana" <psoft@latino.net.co> wrote in message
news:3ad09992@news.devx.com...
> " This changes will all be implemented in the Visual Studio.NET Beta 2:
>
> *Declaring Arrays: For consistency with other languages, Microsoft
> intended to change the way VB declared arrays, so that you would
> specify the number of elements in the array: Dim a(10) As Integer would
> create a ten-element array, with an upper bound of 9. This conflicts
> with the VB style of declaring arrays, where Dim a(10) As Integer
> creates an eleven-element array with an upper bound of 10. The
> traditional declaration technique has been restored. "
>
> So,
> * To my I liked how BETA1 operates the arrays in VB.NET.
> * In any case, I think that VB.NET would have to maintain the "TO"
> - The old code as Dim X(n1 TO n2) will be a serious problem.
> ________________________________
> Harvey Triana... psoft@latino.net.co
> Microsoft Developer MVP- Visual Basic
> www.eidos.es/VeXPERT
>
> "Bill McCarthy" <bill_mcc@iprimus.com.au> escribió en el mensaje
> news:3acffbf0@news.devx.com...
> > Hi all,
> >
> > thought it must be my turn to start a thread here <g>
> >
> > In VB.NET, the proposed syntax for declaring arrays as it appears it is
> > goint to be is :
> >
> > Dim a(Ubound) [as Type]
> >
> > In VB5/6 it is
> >
> > Dim a([lBound To] UBound) [as Type]
> >
> > and in other languages such as C# they declare the number of elements as
> is
> > the case with Beta1.
> >
> > I like the fact MS has decided to ensure compatibility with VB5/6, but
the
> > Dim a(UBound) style I don't think is clear to everyone. I can see some
may
> > confuse it with other languages and think it actually means Dim
> > a(number_of_elements).
> >
> > What I would like to see is the IDE use it's smarts features, and
> > automatically update the syntax to the full VB5/6 syntax.
> >
> > IOW:
> >
> > I could type in "Dim a(x)" and the IDE would autoamtically change that
to:
> > Dim a(0 To x)
> >
> > I think that would make the code clear, remove any possible confussion
and
> > also provide compatibility with VB5/6 skills and code.
> >
> >
> > Thoughts ??
> >
> >
> >
> >
> >
> >
>
>

[Bill McCarthy]

Hi Russell,

"Russell Jones" <arj1@northstate.net> wrote in message
news:3ad0ad10$1@news.devx.com...
<snip>
> However, if the rollback to classic VB
> upper bound declaration moves forward, I think that it's a necessity to
> either require the "0 to X" syntax explicitly or for the IDE to expand the
> syntax by adding the "to" keyword so that when you write Dim A(10), the
IDE
> changes it to Dim A(0 to 9), and I would want that syntax enforced across
> all .NET languages.
>

Well on this we agree to some extent, except for the precise details. I
believe it should be Dim A(10) gets expaned to Dim A(0 to 10).
The reasons are pretty simple. First, the only language I am aware of that
uses the "Dim" is VB. So cut and paste ambiguities are removed by having it
as Dim A(Ubound) expands to Dim A(lBound to UBound)
Secondly, for anyone coming from another language the change is immediately
apparent.
and Thirdly, but not lastly <g>, in the case you type in Dim A(x) this would
expand to Dim A(0 to x) whereas yours would expand to Dim A(0 to x-1) which
takes away from the readability.


<huge snip>
> In contrast, if
> the "to" syntax is required for all .NET languages, then you can be
> absolutely certain how many elements the array has--even if, sometime in
the
> future--.NET supports a lower bound for arrays other than 0.
>

exactly !! That is another advantage of the explicit setting of bounds. More
versatile, more compatible, clear, distinct and explicit.

[David]

The Microsoft announcement says, "The traditional declaration technique has
been restored." Most of the discussion seems to assume that this simply means
that Dim a(10) now means that a is an 11-element array, but that the Dim
a(1 to 10) syntax is not being restored. Does anyone know this for a fact?

My bigggest concern is the elimination of explicit lower bounds. I put together
a note to Microsoft describing these concerns a couple of months ago. (The
part of it assuming that the subscripts in Dim a(n) go from 0 to n-1, rather
than 0 to n, is apparently obsolete.) Here's what I wrote:

***************************************************************************

Apparently, VB.NET will not support explicit lower array bounds, and arrays
declared with dimension n will have subscripts from 0 to n-1.

I feel that this change to VB (and, presumably, to VBA) is extremely ill-advised.

First, this will be a very difficult conversion issue. For all arrays which
are currently declared with explicit lower bounds, the DIM statements will
need to be re-coded, and every reference to the arrays will need to be checked.
I would expect that a great proportion of the array references will need
to be revised. In addition, for every single array, if the upper bound is
n, the subscript n is valid in VB6 but will be invalid in VB.NET. Thus, all
array references, even those without explicit lower bounds, will need to
be checked very carefully. I shudder to think of the amount and the difficulty
of converting an application that makes significant use of arrays.

Second, this change eliminates a very useful feature of the language, one
that helps in both readability and maintainability. Many arrays lend themselves
very naturally to explicit lower and upper bounds. My favorite example is
an array of Social Security wage bases, with a value corresponding to each
year from 1951 to some year in the future.

Currently, one could code:

Dim SSWB(1951 to 2000)
Dim yr as Integer
Dim HireYr as Integer
Dim TotSSPay as Double

' Initialize wage base values
SSWB(1951) = 3600
etc.

' Accumulate all the wage bases from year of hire to 2000
TotSSPay = 0
For yr = HireYr to 2000
TotSSPay = TotSSpay + SSWB(yr)
Next yr

Under VB.NET, one would have to code:

Dim SSWB(50)
Dim yr as Integer
Dim TotSSPay as Double

' Initialize wage base values
SSWB(0) = 3600
etc.

' Accumulate all the wage bases from year of hire to 2000
TotSSPay = 0
For yr = HireYr to 2000
TotSSPay = TotSSpay + SSWB(yr - 1950)
Next yr

This is such a step backward! And there doesn't seem to be any advantage
to the change. The generated code, as far as I can tell, would be identical.
So there's no reason to make the change for purposes of compatibility with
other runtime libraries.

[Russell Jones]

Bill:


"Bill McCarthy" <bill_mcc@iprimus.com.au> wrote in message
news:3ad16538@news.devx.com...

> and Thirdly, but not lastly <g>, in the case you type in Dim A(x) this
would
> expand to Dim A(0 to x) whereas yours would expand to Dim A(0 to x-1)
which
> takes away from the readability.
>
You can't have it both ways--either it's more readable as 0 to X (or x-1) or
it's not--the readability has nothing to do with what you type. However, I
do agree that expansion using the number of items syntax would "feel"
strange, e.g. you type Dim A(X) and you get Dim A(0 to x-1).

[Phil Weber]

> Most of the discussion seems to assume that this simply
> means that Dim a(10) now means that a is an 11-element
> array, but that the Dim a(1 to 10) syntax is not being restored.
> Does anyone know this for a fact?

David: Yes.
---
Phil Weber

[Craig Clearman]

Russell,

>In general, I think consistency with other languages is a valid argument
>against making any of the rollback changes announced for VB.NET.

In general, I think the idea that all languages should be consistent
is silly. If they all had the same syntax, they would be the same
language. If they all had similar syntaces, there would be no
advantage in choosing one language over the next.

Having similar syntaces means that the languages all have the same
strengths and the same weaknesses. Only the differences in syntax give
you a rational argument to choose one language over another. Stating
that all languages should converge is exactly wrong. We have different
languages because we have different problems to solve. Conforming all
languages to one base implicitly states that the only problems are
nails, and the only tools you need are hammers.

Furthermore, I doubt corporations will want their projects to use too
much language interoperation, simply because it will increase their
support costs. They will go for it in the sense that they will buy
components that use different languages, but they will not have their
own programmers using different toolsets on the same project.
Suddenly, instead of one person tracking down an incident, you will
require three -- one for each language.

>Remember, there are likely to be a lot more languages than just
>the three we have now.

First, we do not currently have three languages. I'm not even sure
which three you are thinking about. I can't think of any way in this
context to subset languages to give us the number three.

Second, most of the new languages will fade quickly out of existence.
If the .NET frameworks really are ported to legacy systems, like
OS/400, VMS, and MVS, some of them may take off. However, I can't
really see any rational corporation choosing to use COBOL.NET to write
a web service on an W2K server.

Ciao, Craig

[Russell Jones]

"Craig Clearman" <chclear@nospam.please> wrote in message
news:b0n3dtc8ccsc32r***54d9ln87qdf0aiom@4ax.com...
> Russell,
>
> >In general, I think consistency with other languages is a valid argument
> >against making any of the rollback changes announced for VB.NET.
>
> In general, I think the idea that all languages should be consistent
> is silly. If they all had the same syntax, they would be the same
> language. If they all had similar syntaces, there would be no
> advantage in choosing one language over the next.

That's the whole point of the language "flavor" choice in .NET. First-class
..NET languages *should* have equal capabilities (they're not quite equal
right now, but they're close). Your choice of language should be made only
on syntax preferences, not on performance, and not on capabilities. That's
why C# now has the RAD capabilities of VB and VB.NET now has the
infrastructure access of C#.

>
> Having similar syntaces means that the languages all have the same
> strengths and the same weaknesses. Only the differences in syntax give
> you a rational argument to choose one language over another. Stating
> that all languages should converge is exactly wrong. We have different
> languages because we have different problems to solve. Conforming all
> languages to one base implicitly states that the only problems are
> nails, and the only tools you need are hammers.
>
I didn't say that "all languages should have the same syntax" except in the
context of array declarations. However, the idea that we have different
languages because we have different problems to solve is not a viable one in
..NET. In the past, we have had different languages because the capabilities
of the languages have been different. However if all .NET first-class
languages have the same capabilities, then the underlying assumption is
incorrect. At present, the two first-class languages (C# and VB.NET) share
most of the same capabilities--perhaps in the future they'll share 100%.

> Furthermore, I doubt corporations will want their projects to use too
> much language interoperation, simply because it will increase their
> support costs. They will go for it in the sense that they will buy
> components that use different languages, but they will not have their
> own programmers using different toolsets on the same project.
> Suddenly, instead of one person tracking down an incident, you will
> require three -- one for each language.
>
You're probably correct--at the project level, but that doesn't alter the
probability that corporations will write different projects in different
..NET languages, nor that programmers will probably need to move between
languages when changing projects or jobs. It also does not address the point
I made, which was that it makes it harder for people to assimilate code
examples written in other languages, and makes VB.NET a less palatable
choice for people moving between .NET languages.

> >Remember, there are likely to be a lot more languages than just
> >the three we have now.
>
> First, we do not currently have three languages. I'm not even sure
> which three you are thinking about. I can't think of any way in this
> context to subset languages to give us the number three.
>
I'm thinking of VB.NET, C# and JScript.NET--which are the three .NET
languages you can use now. Of course, you can also use C++ to write managed
code, so I should have said four.

> Second, most of the new languages will fade quickly out of existence.

That remains to be seen. The fact that there are so many languages being
ported to .NET shows that non-mainstream languages have not faded out of
existence.

> If the .NET frameworks really are ported to legacy systems, like
> OS/400, VMS, and MVS, some of them may take off. However, I can't
> really see any rational corporation choosing to use COBOL.NET to write
> a web service on an W2K server.
I would say that depends on your existing employees' skills. Why would you
retrain your COBOL programmers to write in C# or some other .NET language if
COBOL.NET is available and works?
>

[Craig Clearman]

Russell,

>That's the whole point of the language "flavor" choice in .NET. First-class
>.NET languages *should* have equal capabilities (they're not quite equal
>right now, but they're close).

I have to disagree. Anything that hits the CLS should have a certain
minimum set of capabilities. That doesn't mean that they should have
the same capabilities, though. If APL.NET is limited to the array
processing that you get in C#, there is no reason whatsoever to use
APL.NET.

> Your choice of language should be made only
>on syntax preferences, not on performance, and not on capabilities.

Again I have to disagree. If I'm using Fortran.NET, I should be able
to do a FFT in the most optimized code possible. If I can't do
significant engineering calculations in Fortran.NET, there is no
reason for it to exist.

Each language needs different focus and capabilities. If there weren't
any differences, they do not need to exist.

> That's why C# now has the RAD capabilities of VB and VB.NET now has the
>infrastructure access of C#.

I'm not sure what you mean by "infrastructure access." But it's a bit
ridiculous to think that Visual Fred and C# have actually converged on
anything. C# did not exist, Visual Fred could not have gained
something that C# always had.

>I didn't say that "all languages should have the same syntax" except in the
>context of array declarations.

Why should arrays be held to a different standard? And certainly, you
can't have that one stand up. How could you fit Scheme.NET into your
array declarations?

>However, the idea that we have different
>languages because we have different problems to solve is not a viable one in
>.NET.

It is the only way that multiple languages can remain viable. If two
languages have the same capabilities, developer preference does not
even enter into the equation. Any corporation is going to say: "I know
you like language X, but get over it!" It will extend above
corporations after that, as industries converge on a choice or two,
because it saves them money to have a ready pool of developers. Soon
an industry commentator like Gartner would say: "Best practices
dictate that you use language Y to solve this problem."

> In the past, we have had different languages because the capabilities
>of the languages have been different. However if all .NET first-class
>languages have the same capabilities, then the underlying assumption is
>incorrect.

If all .NET languages have the same capabilities, then only one or two
will exist, even in the medium term. All others will be dropped in the
marketplace, because there is no benefit to supporting 30 ways of
doing the same thing.

>> Furthermore, I doubt corporations will want their projects to use too
>> much language interoperation, simply because it will increase their
>> support costs. ...[snipped]
>>
>You're probably correct--at the project level, but that doesn't alter the
>probability that corporations will write different projects in different
>.NET languages, nor that programmers will probably need to move between
>languages when changing projects or jobs.

They won't write projects in multiple languages either, because they
will want to be able to transfer people around easily. This is the
reason behind standardization committees. The corporation will pick
one language to solve a particular problem architecture. Everyone in
development will be hired, and trained, towards that solution.

> It also does not address the point
>I made, which was that it makes it harder for people to assimilate code
>examples written in other languages, and makes VB.NET a less palatable
>choice for people moving between .NET languages.

I hope this is clearer, then. There will not be this great
assimilation, in my opinion. There is not going to be a great
diversity of language examples used in production. Most people will
settle into two or three languages. Most people who currently look for
VB examples will look exclusively at Visual Fred examples. Some people
will be conversant in both, and will translate C# examples to Visual
Fred, feeding this larger group.

And any magazine that wastes its time publishing two copies of source:
one in Visual Fred, and the other in C# will quickly learn how silly
they are being. They will not want to use valuable space to show how
the "if (True) {" turns into "If True Then". That's just a huge cost
(in space and cost of paper), gaining very little. I would not want to
read a magazine that provided the same snippet in multiple languages.

>> Second, most of the new languages will fade quickly out of existence.
>
>That remains to be seen. The fact that there are so many languages being
>ported to .NET shows that non-mainstream languages have not faded out of
>existence.

I'm not saying the languages are going away -- they will continue,
certainly. It's the .NET versions that are going to fade away. Outside
of .NET, these languages will continue to thrive, because they are
better at solving particular solutions than .NET.

>> If the .NET frameworks really are ported to legacy systems, like
>> OS/400, VMS, and MVS, some of them may take off. However, I can't
>> really see any rational corporation choosing to use COBOL.NET to write
>> a web service on an W2K server.
>I would say that depends on your existing employees' skills. Why would you
>retrain your COBOL programmers to write in C# or some other .NET language if
>COBOL.NET is available and works?

Because there is more to retraining a person than the language chosen.
They have to deal with the new architectures. They have to deal with
the new design techniques. They have to deal with new toolsets. They
have to deal with new operating systems. They have to deal with new
deployment practices. Almost all employers are going to hire new
people or completely retrain existing people; they won't go half-way.
They recognize that having a hybrid shop actually increases costs when
turnover occurs. Besides, COBOL is not well designed for making a web
service.

Ciao, Craig

[Larry Triezenberg]

Well, if we got a vote (which we don't <g>), I'd vote for having the option to
specify using either the current syntax OR the Beta1 syntax using optional
parameters as in:
Dim a([[lBound To] UBound], [numEls]) [as Type]

They you could specify either:
Dim x(0 to 9) or Dim x(,10)

BTW, does the colon-equal syntax still work (I don't have it loaded on this
box), if it does then you could specify:
Dim x(Ubound:=9) or Dim x(numEls:=10)
which would alleviate the potential ambiguity...

(Bill, sorry for hitting the reply button rather than the reply-group button
yesterday!)

"Bill McCarthy" <bill_mcc@iprimus.com.au> wrote in message
news:3acffbf0@news.devx.com...
> In VB5/6 it is
> Dim a([lBound To] UBound) [as Type]
> and in other languages such as C# they declare the number of elements as is
> the case with Beta1.
<snip>
> IOW:
> I could type in "Dim a(x)" and the IDE would autoamtically change that to:
> Dim a(0 To x)
>
> I think that would make the code clear, remove any possible confussion and
> also provide compatibility with VB5/6 skills and code.