array declarations in VB.NET


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 15 of 15

Thread: array declarations in VB.NET

  1. #1
    Bill McCarthy Guest

    array declarations in VB.NET

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







  2. #2
    Larry Serflaten Guest

    Re: array declarations in VB.NET


    "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





  3. #3
    Bob Butler Guest

    Re: array declarations in VB.NET


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




  4. #4
    Craig Clearman Guest

    Re: array declarations in VB.NET

    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


  5. #5
    Jonathan Allen Guest

    Re: array declarations in VB.NET

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




  6. #6
    Harvey Triana Guest

    Re: array declarations in VB.NET

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




  7. #7
    Russell Jones Guest

    Re: array declarations in VB.NET

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

    >
    >




  8. #8
    Bill McCarthy Guest

    Re: array declarations in VB.NET

    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.








  9. #9
    David Guest

    Re: array declarations in VB.NET


    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.






  10. #10
    Russell Jones Guest

    Re: array declarations in VB.NET

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





  11. #11
    Phil Weber Guest

    Re: array declarations in VB.NET

    > 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



  12. #12
    Craig Clearman Guest

    Re: array declarations in VB.NET

    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


  13. #13
    Russell Jones Guest

    Re: array declarations in VB.NET


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





  14. #14
    Craig Clearman Guest

    Re: array declarations in VB.NET

    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


  15. #15
    Larry Triezenberg Guest

    Re: array declarations in VB.NET

    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.




Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center