Re: Wish I was using .net



"Michael C" <nospam@xxxxxxxxxx> wrote in message
news:OIytzqcNGHA.208@xxxxxxxxxxxxxxxxxxxxxxx
"Lance Wynn" <LanceWynn@xxxxxxxxxxxxxxxx> wrote in message
news:%23Pms0hcNGHA.2704@xxxxxxxxxxxxxxxxxxxxxxx
Oh,
Then I have to agree with MikeD, that's just the way the language is.
In
.NET, or any language for that matter you'll find a number of runtime
errors
that for whatever reason the compiler won't catch. It has nothing to do
with the language, or the compiler.

But VB is a leaky sieve in this regard missing a *lot* of errors that it
should have caught. You want the language to do as much as possible
catching
every error it can, leaving the less obvious stuff up to the programmer or
tester.


I concur. I have worked with weakly typed languages and strongly typed
languages and definitely prefer strongly typed languages. Having the
compiler catch as many errors as possible is far better than catching them
at runtime. Remember it's always cheaper (and less embarrasing) to fix a
problem before release than after release.

Dotnet on the other hand is very tight and the one and only situation I
can
think of is a foreach statement, which doesn't check the type until
runtime.

VB 2005 catches type casting errors in for each ... next statements.


There are a number of instances in VB
where you wouldn't want the compiler to raise an error at compile time
if
there were a potential type mismatch.

No, you never want this. A language should always give you an error for
any
implicit type conversion that could cause an error or loss of data, and
force you to explicitly do a conversion.

Michael


I just wish MS hadn't thrown out the baby with the bathwater when
modernizing VB 6. As may people in this NG have correctly pointed out, MS
made a lot of changes to the VB language that break a lot of existing code.
I suspect many of these changes were unnecessary, despite the protestations
of the MS VB development team.

Mike Ober.



.

Relevant Pages

  • Re: "STL from the Ground Up"
    ... high-level intermediate language than can interoperate with many other ... If your language lacks expressive features then you cannot write code ... memory management in comparison. ... Mostly because type errors mean that the programmer and compiler disagree ...
    (comp.programming)
  • Re: A note on computing thugs and coding bums
    ... It would handle international characters if the execution character ... method I used in "Build Your Own .Net Language and Compiler". ... work areas and counting on Nul is an illusion. ...
    (comp.programming)
  • Re: WaitForSingleObject() will not deadlock
    ... represent an incorrect implementation of the language. ... the *compiler* does not guarantee this. ... but to state it in terms of the execution instead of the formal semantics of the language ... as long as the optimizations do not change the semantics of the language). ...
    (microsoft.public.vc.mfc)
  • Re: "STL from the Ground Up"
    ... If your language lacks expressive features then you cannot write code well ... Same program is 5x faster in OCaml than C++. ... The compiler infers the types of all subexpressions for you and makes them ... virtual const Base *clone= 0; ...
    (comp.programming)
  • Re: "STL from the Ground Up"
    ... are not features of a language. ... To support reflection you make a compiler embbed type and functional information in the compiled program. ... When the OCaml compiler is given a complicated nested pattern match it ... virtual const Base *clone= 0; ...
    (comp.programming)