A new article for MSDN Mag. was posted on Generics, just FYI:

http://msdn.microsoft.com/msdnmag/is...T/default.aspx


~
Jeremy

"Jeremy Cowles" <jeremy.cowles[nosp@m]asifl.com> scripsit:
> A new article for MSDN Mag. was posted on Generics, just FYI:
>
> http://msdn.microsoft.com/msdnmag/is...T/default.aspx

Thanks for the info. The article doesn't cover generics in VB.NET...

:-)

--
Herfried K. Wagner
MVP · VB Classic, VB.NET
<http://www.mvps.org/dotnet>

"Herfried K. Wagner [MVP]" <hirf-spam-me-(E-Mail Removed)> wrote in message
news:bm1lu7$gqa13$(E-Mail Removed)...
> "Jeremy Cowles" <jeremy.cowles[nosp@m]asifl.com> scripsit:
> > A new article for MSDN Mag. was posted on Generics, just FYI:
> >
> > http://msdn.microsoft.com/msdnmag/is...T/default.aspx
>
> Thanks for the info. The article doesn't cover generics in VB.NET...

Well, no, but the spec for VB generics has not yet been released. I just
thought it was interesting to see how the CLR supports generic programming
and expands it by adding metadata into the mix. I'm sure the VB
implementation won't be that far off from C#.

"Jeremy Cowles" <jeremy.cowles[nosp@m]asifl.com> scripsit:
> > > A new article for MSDN Mag. was posted on Generics, just FYI:
> > >
> > > http://msdn.microsoft.com/msdnmag/is...T/default.aspx
> >
> > Thanks for the info. The article doesn't cover generics in VB.NET...
>
> Well, no, but the spec for VB generics has not yet been released. I just
> thought it was interesting to see how the CLR supports generic programming
> and expands it by adding metadata into the mix. I'm sure the VB
> implementation won't be that far off from C#.

Yep, it's really interesting!

--
Herfried K. Wagner
MVP · VB Classic, VB.NET
<http://www.mvps.org/dotnet>

Jeremy,
Don't forget about the second part of the article also posted:

http://msdn.microsoft.com/msdnmag/is...T/default.aspx

Hope this helps
Jay

"Jeremy Cowles" <jeremy.cowles[nosp@m]asifl.com> wrote in message
news:AjVgb.80086$(E-Mail Removed)...
> A new article for MSDN Mag. was posted on Generics, just FYI:
>
> http://msdn.microsoft.com/msdnmag/is...T/default.aspx
>
>
> ~
> Jeremy

This article is another example of why strong typing in an OO language is
totally unnecessary. I have used an untyped OO language for many years on
large (2000+ classes) projects with many different programmers(20+) and we
never had a problem with not having strong type checking. Strong typing may
have been necessary in structured languages such as C, C++, Pascal, etc.
but with OO languages it is just a burden. I think VB would be better off
moving away from strong type checking, not trying to "work-around" it.

Gary

"Jeremy Cowles" <jeremy.cowles[nosp@m]asifl.com> wrote in message
news:AjVgb.80086$(E-Mail Removed)...
> A new article for MSDN Mag. was posted on Generics, just FYI:
>
> http://msdn.microsoft.com/msdnmag/is...T/default.aspx
>
>
> ~
> Jeremy

"Gary Owsiany" <gar-(E-Mail Removed)> wrote in message
news:ROehb.489$(E-Mail Removed)...
> This article is another example of why strong typing in an OO language is
> totally unnecessary. I have used an untyped OO language for many years on
> large (2000+ classes) projects with many different programmers(20+) and we
> never had a problem with not having strong type checking.

But the real question is, have you used a strongly typed language as
extensivly to see the benifits? Many bugs that you were plagued with in the
past disappear without any effort at all, because these bugs are caught by
the compiler. Unless your team was a group of perfect, super-programmers who
*never* sent in the wrong type, say for example, to a method that expected a
different type.


> Strong typing may
> have been necessary in structured languages such as C, C++, Pascal, etc.
> but with OO languages it is just a burden. I think VB would be better off
> moving away from strong type checking, not trying to "work-around" it.

Just program in VB script, or KI (a VBA based IDE with forms and integration
tools)! =) Generics in .NET are strongly typed, and they are definitly not
a 'work-around'. That is one of the main points of Generics, they are
strongly typed, but the type can be changed to suite any need with out
rewriting code. Perhaps you could explain the benefits of the opposite (for
arguements sake, I am not trying to attack your preference).

Of course, you have the right to your beliefs and to program however you see
fit, but I personally disagree.

~
Jeremy

"Jeremy Cowles" <jeremy.cowles[nosp@m]asifl.com> wrote in message
news:XWxhb.12670$(E-Mail Removed)...
> "Gary Owsiany" <gar-(E-Mail Removed)> wrote in message
> news:ROehb.489$(E-Mail Removed)...
> > This article is another example of why strong typing in an OO language
is
> > totally unnecessary. I have used an untyped OO language for many years
on
> > large (2000+ classes) projects with many different programmers(20+) and
we
> > never had a problem with not having strong type checking.
>
> But the real question is, have you used a strongly typed language as
> extensivly to see the benifits? Many bugs that you were plagued with in
the
> past disappear without any effort at all, because these bugs are caught by
> the compiler. Unless your team was a group of perfect, super-programmers
who
> *never* sent in the wrong type, say for example, to a method that expected
a
> different type.
Yes, I programmed in Pascal, C and C++ for many years before moving to
Smalltalk. I was shocked to discover how much "code" I had been writing to
satisfy the compiler. In Smalltalk I was able to concentrate on the
"business problem" I was trying to solve, rather than trying to make sure I
had the right "type" that satisfied the compiler or trying to make sure I
cast one type into another type to satisfy the compiler. That was an
immediate productivity boost, and as we all know a more productive
programmer is one of the goals of software development.
Smalltalk handles the problem of sending a message to a wrong Object very
simply, the object simply returns "Does not understand" and displays a
debugger showing the offending message. These bugs are almost always
discovered during Unit test and quickly fixed. The point is, it doesn't
take a "super-programmer" to write robust software solutions in Smalltalk.
On the contrary, I find trying to keep up with all the strong-typing in
VB.Net is much more difficult and time consuming. And as I said before, it
does not add any value. From a cost-benefit standpoint, it is not cost
effective to enforce strong type checking. I have a degree in Computer
Science and I know the "theoretical" arguments for strong type checking, but
some times the practical implementation refutes the theory, as in this case.
>
>
> > Strong typing may
> > have been necessary in structured languages such as C, C++, Pascal, etc.
> > but with OO languages it is just a burden. I think VB would be better
off
> > moving away from strong type checking, not trying to "work-around" it.
>
> Just program in VB script, or KI (a VBA based IDE with forms and
integration
> tools)! =) Generics in .NET are strongly typed, and they are definitly
not
> a 'work-around'. That is one of the main points of Generics, they are
> strongly typed, but the type can be changed to suite any need with out
> rewriting code. Perhaps you could explain the benefits of the opposite
(for
> arguements sake, I am not trying to attack your preference).
>
> Of course, you have the right to your beliefs and to program however you
see
> fit, but I personally disagree.
My question to you is have you ever programmed in an untyped language like
Smalltalk? I have yet to meet a Smalltalk programmer who has programmed in
some other language (including COBOL, VB, etc.) who has said that he wants
strong type checking in Smalltalk, and I suspect the same would be true for
you. Unfortunately, the Smalltalk programming environment is so radically
different from other languages that it never "caught-on" so it's just been
relegated to a niche environment. I guess talking to someone about
switching to Smalltalk is like switching word processors or editors, once
one gets comfortable using a certain application, he is unwilling to try
something new and different (even if it would make him more productive). I
like many things about VB.Net and I am glad that it has come such a long
way, it's just that I know for a fact that enforcing strong type checking is
a waste of time because I haven't needed it for the past 13 years, and it
feels like a giant step backwards to have to start using it again.

Gary

Hi Gary,
I never did something in Smalltalk, but I have the same feelings as you
write.

The first programs I had to make where for the IBM 360 system.
There I had to do with formats (who I had to describe) if I had to bring a
variable from register to register (I believe it even exist) or from
register to memory and all things between.

Then we got better program languages like COBOL, I was freed from that,
because the computer took that work over from me.

Now I see it come back and the computer does not give me any help than
giving me an answer that I did it wrong.

Is it such a hell of a job, when I make a program that has a sender, to let
the computer do the job and check what object it can be. I don't think
so.And that is especially not when it is just in a standard event that has a
signature that only is with that object.

I can make it longer, but it was only to say that I agree with you.

Cor