Microsoft.VisualBasic.dll
Hans Blomme
--
Hans Blomme
JP Hamilton
"Hans Blomme" <hans....@yucom.be> wrote in message news:OHF4d1S7AHA.2016@tkmsftngp03...
Hans Blomme
--
Hans Blomme
"JP Hamilton" <jp...@swbell.net> wrote in message news:up$CYiT7AHA.2216@tkmsftngp07...
JP Hamilton
"Hans Blomme" <hans....@yucom.be> wrote in message news:#IJiT4c7AHA.1620@tkmsftngp05...
Rockford Lhotka
"Hans Blomme" <hans....@yucom.be> wrote in message news:#IJiT4c7AHA.1620@tkmsftngp05...
Kathleen Dollard
I do not agree that a tendency to direct use of the framework classes rather
than VBcompatiblity wrappers results in
>> Code that is in that middle-place will be really hard to deal
>> with in the long run I think.
--
Kathleen
(MS-MVP)
Reply in the newsgroup so everyone can benefit
--
Rockford Lhotka
compatibility area upon release of the product. The things that end up left
in that namespace upon release (not in beta 1) really are there for ease of
migration and generally should be avoided.
However, the question was about Microsoft.VisualBasic.dll, which also
includes the entire Microsoft.VisualBasic namespace. That namespace includes
a huge amount of functionality that I believe is absolutely core to the
identity of VB - every bit as much as the keywords that 'really' make up the
language.
I've been writing apps with various forms of Basic for over 20 years and
find it hard to imagine writing a Basic app without Left() or Right() for
instance. And there are countless other functions that are simply 'part of
Basic' or 'part of VB'. Totally abandoning them just boggles the mind.
That would be like taking the C runtime library away from C developers and
telling them that they are still doing C programming. Technically perhaps
they would be - but no C developer in their right mind would agree to
abandon functions that have been around so long, ingrained in the language
so deeply that they are virtually indistinguishable from the language
itself.
Same thing with VB. The Microsoft.VisualBasic namespace - Beta 2 and
onward - includes functionality that I believe is absolutely the VB
equivalent to the C runtime library. While _technically_ you can do VB
without it, it is incredibly dubious as to whether what you'd be writing is
VB or Visual Fred. At that point you are just using a slightly more verbose
version of C#.
VB is not the only language that will face this. Most languages are like C
and VB in that they have a runtime library of functions that over the years
have become relatively indistinguishable from the language itself in the
minds of developers. It seems unreasonable to expect that VB developers
should abandon their runtime library because of some presumed
C-style-language-envy, while COBOL, Smalltalk, Eiffel and other language
users presumably will get to use _their_ runtime libraries without facing
the same prejudices.
Frankly, if you take away the VB runtime library in Microsoft.VisualBasic
then you've effectively eliminated any reduced learning curve that VB.NET
might have for the typical VB developer - totally neutralizing the language
benefit and making the jump to .NET totally equivalent to a jump to Java.
And perhaps that's what some people would like to see happen - that way we
can all join the legions of semi-colon/squiggly-bracket lovers regardless of
platform ;) (not that I think that of you Kathleen)
Rocky
--
Rockford Lhotka
ro...@lhotka.net http://www.lhotka.net
"Kathleen Dollard" <Kath...@noemailplease.com> wrote in message
news:e8mEW6g7AHA.1660@tkmsftngp04...
JP Hamilton
"Rockford Lhotka" <ro...@lhotka.net> wrote in message news:OIxdQYg7AHA.1416@tkmsftngp05...
Kathleen Dollard
I dunno. I am certainly not advocating ignoring the VisualBasic namespace at
this time, although I will probably not use it much unless it becomes a best
practice in shops where I am working. The question is
s = "VisualFred"
s = Left$(s,6) & " Basic"
or
s = s.Substring(0,6) & " Basic"
I see VB.Net as a brand new language that happens to build on the
familiarity of VB. Specifically, it is a line delimited language. Beyond
conversions, is there a benefit to having things look the way they have
before? Some benefit because Left initially comes to mind. But I am finding
this changing very rapidly, and anticipate soon being as familiar with the
base object model as I was with VB.
I prefer the look of base class code. I am not looking forward to projects
where programmers mix styles though. I think this conversation needs to play
out in shops and encouragement->rules (depending on shop culture) to one
style or the other as dotnet becomes available.
Here is my main argument for the baseclass style. Most things can be done
through the base classes, the things we have done in the past can also be
done through VB functions (let's ignore performance for this argument). In
two years, I am going to be using the base classes smoothly for all the
things that the functions do not do. I will have to be familiar with it. I
do not want, nor do I want anyone working on a project with me, to break the
flow in wondering whether there is a VB equivalent. There will be things
that we need the base classes for, and I am not excited about cluttering up
my own code with mixed styles because some stuff must be done in base class
style and some things can be done in VB function style.
My secondary argument is that within three years I am far more likely to
also be reading C# code than to also be reading VB6 code. I don't think I
will forget it and I certainly think people cross training in VB6 will be
extremely rare in a couple of years. Cross-training in C# is far more
likely.
Just my $.02. Glad you are bringing this issue up.
Larry Serflaten
> I see VB.Net as a brand new language that happens to build on the
> familiarity of VB. Specifically, it is a line delimited language. Beyond
> conversions, is there a benefit to having things look the way they have
> before? Some benefit because Left initially comes to mind. But I am finding
> this changing very rapidly, and anticipate soon being as familiar with the
> base object model as I was with VB.
I think you will be hard pressed to become as familiar with the entire object
model as you might have been with VB. What you might learn are the patterns
the model has, so that you can deduce how to find what you need and infer
how to use it, but IMO there is simply to much there for most people to keep
it all fresh in their mind.
For example, how long do you suppose you will spend on 'memorizing' all
of the named colors?
>
> I prefer the look of base class code. I am not looking forward to projects
> where programmers mix styles though. I think this conversation needs to play
> out in shops and encouragement->rules (depending on shop culture) to one
> style or the other as dotnet becomes available.
>
It is not going to be cut and dried, one style or the other, it is going to be a sliding
scale, with familar VB statements intermixed with .Net object references. Most
people are naturally going to get familiar with the objects they use most often.
The areas using the Net objects they know could look more like your New.Net
style, where that same person would resort back to classic VB for the lessor known
areas. Yes, you could enforce certain rules, but that is going to slow production
as programmers keep translating what they used to know (VB) into what the rules
demand (.Net) And, IMHO, such rules will slow the learning process significantly....
>
> My secondary argument is that within three years I am far more likely to
> also be reading C# code than to also be reading VB6 code. I don't think I
> will forget it and I certainly think people cross training in VB6 will be
> extremely rare in a couple of years. Cross-training in C# is far more
> likely.
If past performance is an example of what is ahead, cross-training to C#
will be mandatory, in that all the cool tips and tricks will be shown in C#....
<g>
LFS
Bob Butler
news:O3VglH07AHA.2216@tkmsftngp07...
> "Kathleen Dollard" <Kath...@noemailplease.com> wrote
<cut>
> What you might learn are the patterns
> the model has, so that you can deduce how to find what you need and infer
> how to use it, but IMO there is simply to much there for most people to
keep
> it all fresh in their mind.
True, but learning the major objects and the patterns, coupled with the
Intellisense in the IDE, should make it almost as fast to use methods you
don't know as those you do. Now that I find to be a wierd concept!
<cut>
> Yes, you could enforce certain rules, but that is going to slow production
> as programmers keep translating what they used to know (VB) into what the
rules
> demand (.Net) And, IMHO, such rules will slow the learning process
significantly....
For developers who use both VB.Net and VB6 on a regular basis there may be
an advantage to retaining the VB6-style methods in many cases. It will make
the switch back and forth less prone to time-wasting errors if they just
always use Left() instead of .SubString() for example. OTOH, developers who
use VB.Net almost exclusively may benefit from adopting the dotnet-style
(for lack of a better term) as quickly as possible.
I think that dichotomy has been the heart of the VB.Net/VB.Not debate from
the start and I think it's very important to understand that those two types
of developers exist, and will exist for some time (the type, I have no idea
how long the individual developers will exist <g>).
<cut>
> If past performance is an example of what is ahead, cross-training to C#
> will be mandatory, in that all the cool tips and tricks will be shown in
C#....
>
And I still fully expect that within a few years VB.Net will begin to die
and only C# will be left. Anybody who has learned to work with the
dotnet-style may be more able to adapt.
Jens Samson
> and only C# will be left. Anybody who has learned to work with the
> dotnet-style may be more able to adapt.
And I still think that there are enough people out there who really, really, really hate curly braces and the cryptic syntax of any
C-like language (in fact, I'm sure that's the major reason there is a market for Delphi).
Jens
Rockford Lhotka
news:ej11SV17AHA.1416@tkmsftngp05...
> And I still fully expect that within a few years VB.Net will begin to die
> and only C# will be left. Anybody who has learned to work with the
> dotnet-style may be more able to adapt.
You know, the semi-colon-cowboys have been saying this sort of thing for
15-20 years.
Somehow I am not convinced that a semi-colon and rather cryptic C-style
syntax is the be-all and end-all of computing. Then again, I (like a lot of
people) wasn't trained in a C-style language, but rather come from different
roots (FORTRAN, etc.)
It could be that eventually the semi-colons will rule - but over the past
15-20 years it has consistently been non-semi-colon languages that have
dominated the market in terms of overall usage.
The fact is that we should be striving to make programming languages LESS
machine-friendly and more HUMAN-friendly. The people who conceived of COBOL
and BASIC and SQL had the right idea - we're simply still trying to find the
right combination to achieve their original goal of a human-readable
language for computing.
Though it is admittedly a very subjective thing - I believe that VB is a lot
more human-friendly than C# or C++ or Java. There are less little niggly
syntax issues to remember on a line by line basis - and that makes the
language more accessibly and approachable by regular people.
Rockford Lhotka
"JP Hamilton" <jp...@swbell.net> wrote in message news:#BfrqLj7AHA.1276@tkmsftngp03...
Bob Butler
> "Bob Butler" <butl...@earthlink.net> wrote in message
> news:ej11SV17AHA.1416@tkmsftngp05...
> > And I still fully expect that within a few years VB.Net will begin to
die
> > and only C# will be left. Anybody who has learned to work with the
> > dotnet-style may be more able to adapt.
>
> You know, the semi-colon-cowboys have been saying this sort of thing for
> 15-20 years.
Don't misunderstand me --- I'm not saying C# is better than VB.Net or that
it "should" replace it. That's a very different discussion. I'm basing
that comment on several assumptions/opinions:
1) VB.Net is more initimdating to many, especially those who don't use
classes much now
2) Many of MS's "6 million" (pick your number du jour) VB developers fall
into the above group
3) Many current users of VB will not migrate to VB.Net because of the
perceived complexity
4) VB still is, and IMO always will be, looked down upon by C/Java/whatever
developers
5) Microsoft may provide VB.Net samples and apps, but they will be converted
from C# versions
6) Microsoft is supporting both C# and VB.Net, extending both roughly in
parallel
7) C# and VB.Net target the same developer level and application types
8) #6 requires a fair amnount of investment by Microsoft, #7 indicates that
this is duplicated effort
9) The percentage of VB users in #3 may drop far enough for #6 to become
less cost effective
MS could have produced the dotnet platform and just VB.Net without
developing or releasing C# at all. Developing C# was probably smart in that
it becomes a very attractive alternative to current C++ and Java developers
who would not sink to the level of using VB (not my opinion personally).
Another option would have been to release C# without developing VB.Net but
that would have alienated a very large number of users. A third option is
to develop and seriously commit to maintaining both C# and VB.Net and that's
what MS is claiming, and I'll be quite happy if they stick to that
commitment. A fourth option, which is what my more cynical side is
expecting, is that VB.Net was developed as a stopgap to migrate current VB
developers into the OO world and give them some time to learn C# also so
that in a few years VB.Net can be scrapped without losing a sizable chunk of
the developer market.
I could be wrong. In many ways I hope that I am wrong. I'm just not
convinced that a case can be made for long-term support of two languages
with no significant differences in target markets.
JP Hamilton
Dim c As Char
'Do something with char here
Next c
Rick Barnett
> I could be wrong. In many ways I hope that I am wrong. I'm just not
> convinced that a case can be made for long-term support of two languages
> with no significant differences in target markets.
I think you're right, for the wrong reasons :-) Microsoft wants, I'm sure,
to put out the best tools for all involved. VB'ers get VB.NET and C++/Java
guys get Managed C++, C#, JScript. The more the merrier as far as Microsoft
cares. The reason I see one .NET language dominating the future has more to
do with Sun than Microsoft, unfortunately.
Bob Butler
news:#H10b357AHA.1812@tkmsftngp04...
The reasons I gave were just looking at MS products and the fact that it
rarely makes sense for a business to compete against itself. VB and C++
have distinct enough developer markets that they aren't in direct
competition. I can't say the same for VB.Net and C#. Pressures on
Microsoft from other companies, like Sun, may influence the speed at which
things change but I don't see them as majority factors in the demise of
VB.Net. If anything, I'd say having multiple functionally-equivalent
languages is a good marketing tactic since it offers the
curly-brace/semicolon-haters an alternative. I just don't see that as
enough to justify maintaining VB.Net long-term.
Larry Serflaten
"JP Hamilton" <jp...@swbell.net> wrote
Well I don't know if I am a typical developer or not. I know C/C++ fairly well but most of the contract work I get is VB. I
have been using VB since the first day version 2.0. Thats about what, 10 years ago?
I have been working with VB.NET in depth for about 2 months because of a book I am working on for O'Reilly. What I am finding
is that VB.NET is just as easy to use as VB ever was. The .NET class library is organized so well, and is so powerful, that
it seems to offset any learning difficulties.
-----------------------------
I don't have any statistical data on the language dispersion between programmers, personally I started learning programming
with Basic (1982), then moved to a C/Pascal derivative, and in the process learned ML to further tweek performance, and now
have settled back to Basic... I have been using VB since 1995 (VB3 - VB5) and look forward to learning the .Net platform.
What I can't agree with is the learning curve that will be present for anyone who has not been exposed to these other lower
level languages. There is word out there that several VB programmers do not use classes, and I have to then wonder how many
actually use the API? It is those people, who never really used the API (except for cut and paste tricks) that will find a
steeper learning curve when transitioning to .Net.
-----------------------------
"JP Hamilton" <jp...@swbell.net> wrote
Left and Right are cool, but using Mid to search through a String one character at a time is a pain in the ass. It always has
been. I'll take the .NET way any day:
Dim s As String = "this is a test"
Dim c As Char
For Each c in s.ToCharArray()
'Do something with char here
Next c
-----------------------------
This is (IMHO) exactly the sort of thing that needs to be addressed. Intellisense may list 'ToCharArray' in the drop down
list for s, but that does nothing to tell the programmer what it does, or how to use it. Examples like the above do both....
-----------------------------
"JP Hamilton" <jp...@swbell.net> wrote
I ask you this - what is more clear? Declaring an array with the number of elements it contains or using the upper bound?
"Uh, dude, I know it says Dim x(7) As Integer, but,uhh, there are really 8 in there".
-----------------------------
If the programmer has not yet learned that computers consider 0 a valid index, then he is farther behind the times than you
might think! IMO using upper bound will reduce the off-by-one errors that would otherwise happen:
Const MaxSize = 100
Dim Data(MaxSize) As Long
...
For i = 0 to MaxSize
'Do stuff
Next
Is considerably more 'convenient' than
For i = 0 to MaxSize - 1
... etc.
Or even: Dim Data(MaxSize + 1) As Long (so that MaxSize can be used w/o problems)
-----------------------------
"JP Hamilton" <jp...@swbell.net> wrote
Personally, I think VB.NET feels like VB. It took NO time at all to become comfortable with it. I have to say that for the
most part, I like it, too.
-----------------------------
I agree, I think I will like it too....
BTW it would be more considerate to post plain text to the newsgroups FWIW...
LFS
Rick Barnett
> The reasons I gave were just looking at MS products and the fact that it
> rarely makes sense for a business to compete against itself. VB and C++
> have distinct enough developer markets that they aren't in direct
> competition. I can't say the same for VB.Net and C#. Pressures on
> Microsoft from other companies, like Sun, may influence the speed at which
> things change but I don't see them as majority factors in the demise of
> VB.Net. If anything, I'd say having multiple functionally-equivalent
> languages is a good marketing tactic since it offers the
> curly-brace/semicolon-haters an alternative. I just don't see that as
> enough to justify maintaining VB.Net long-term.
VB.NET will justify itself, even if only through ASP.NET and VSA in Office.
The reason I credit Sun is that Java has become such a large influence
outside of Windows, it seems likely to lift C# in .NET as shops look to
standardize on that class of tools. VB.NET is the odd boy out.
Rick B.
JP Hamilton
quickly learn the error of his ways in .NET. It's not like this will cause
some hard to find error like it would in C.
But this syntax would pretty much alleviate the problem you addressed:
Const MaxSize = 100
Dim Data(MaxSize) As Long
Dim num As Long
For Each num In Data
'Do stuff
Next num
Bob Butler
<cut>
> Dim Data(MaxSize) As Long
The syntax that needs to be supported is:
Dim Data(0 To upperbound) As Long
immediately obvious what it means and leaves the syntax consistent for (I
hope) the eventual return of non-zero lower bounds
Bob Butler
<cut>
Interesting. VSA in office is something I expect to fail big time. Most
Office VBA developers I've ever seen don't handle VBA's OO capabilities now
and I expect they'll really dislike VSA.
> The reason I credit Sun is that Java has become such a large influence
> outside of Windows, it seems likely to lift C# in .NET as shops look to
> standardize on that class of tools. VB.NET is the odd boy out.
I don't disagree, but I still think offering the "odd boy out" to people who
dislike Java or C-style coding makes sense and gives VB.Net a bit of a
reason to exist. I just don't think it's enough to offset the cost of
maintaining both VB.Net and C# in the long term.
Larry Serflaten
"JP Hamilton" <jp...@swbell.net> wrote
> Well, IMHO, thats why God invented exception handling. The programmer will
> quickly learn the error of his ways in .NET. It's not like this will cause
> some hard to find error like it would in C.
They each have their own 'personalities', and with .Net being able to allow any
language to keep its own syntax, as well as work well with other .Net languages,
I think MS has hit a major milestone...
>
> But this syntax would pretty much alleviate the problem you addressed:
True, but then C could just as easily use the same syntax so that those coders
don't get bit if/when they want to pick up VB... <g>
LFS
Rockford Lhotka
>[...]
> I could be wrong. In many ways I hope that I am wrong. I'm just not
> convinced that a case can be made for long-term support of two languages
> with no significant differences in target markets.
You have some very good points.
I think, however, that the issue is broader than this.
I agree that C# came into being because there's no way the C++/Java devs
would move to VB - but they _will_ move to a VB-like managed environment as
long as they have a language rooted in C syntax. That, by itself, justifies
C#.
However, it is equally the case that the _majority_ of VB devs prefer the
simpler and more understandable syntax of VB and will not willingly move to
a C-style language any more than the C people will move to VB. And this
justifies VB.NET.
The reason I am so convinced of this is based on what I believe to be the
fault of one of your key points:
"1) VB.Net is more intimidating to many, especially those who don't use
classes much now"
True, the PDC and even Beta 1 versions of VB.NET are _quite_ intimidating if
you don't use classes. Also, the sample code to date _has_ been either
converted from C# or written in VB by C# devs - and so that code isn't
'real' VB (per my earlier comments about the use of the VB runtime
functions).
However, the VB team continues to put a lot of energy into making VB.NET
look and feel as much like old VB as possible, and we haven't yet seen the
end result of that process. The level of familiarity from the PDC to Beta 1
builds was a tremendous step forward. I expect much more between now and
RTM.
The majority of the 3.7 million (give or take) VB devs today do
code-behind-form programming, not class-based programming. VB.NET will allow
those devs to continue to drag-and-drop, double-click and write code behind
a form without being forced to learn about classes and objects any more than
they do today.
Yes, there is a learning curve. We are getting a new version of VB - which
always causes a learning curve (or at least did, back when a new version
actually changed something - you know, vb 1->2->3->4 - the fact that vb 5
and 6 are just big service packs doesn't count). On top of that we are
undergoing a platform change - which _also_ causes a learning curve.
However, based on what I've seen so far, I am entirely convinced that VB.NET
is going to provide - by far - the easiest migration path for existing VB
devs to move from Windows to .NET. And those devs WON'T have to learn OO
programming to succeed.
As an aside - if you are right, and for some reason VB devs move to VB.NET
and then to C# - I think that the C-style community is in for a shock. It
turns out that you can write code-behind-forms apps in C# too. You can write
C# apps without understanding classes and objects any more than VB devs to
today. Anyone who assumes that the typical VB dev, who is productive without
classes, is going to become and OO programmer just by moving to C# has no
grasp of reality.
IF the VB community moves to C#, we'll find that the _majority_ of C#
programs at that point will be written without substantial or 'correct' use
of classes and objects, but instead rely heavily on code in forms and direct
use of data and all the things that VB devs do to be productive today.
I am left wondering. If that DOES happen - and the C-rooted languages are
overrun by highly productive and pragmatic VB devs - where will the
elitist/purist devs go? Undoubtedly they'll view this whole thing as an
abomination that has ruined their language. Will C# be looked down upon just
like VB is today?
That's the problem with extremist ideology - when you DO manage to bring the
majority into your little clique you often find that your clique has been
fundamentally changed into something you didn't anticipate - and _that_ gets
messy. Fortunately an ideological 'war' in technology is somewhat safer than
the ones waged in the real world with guns and bombs...
Bob Butler
<cut>
> However, the VB team continues to put a lot of energy into making VB.NET
> look and feel as much like old VB as possible, and we haven't yet seen the
> end result of that process. The level of familiarity from the PDC to Beta
1
> builds was a tremendous step forward. I expect much more between now and
> RTM.
I've been a proponent of making VB.Net as compatibile with VB6 just for that
reason. The more they make VB.Net accessible to current VB users the larger
the user base will be and that would justify extending the VB.Net lifetime.
I'm just still too cynical to truly believe that VB.Net has a long-term
future.
I'm obviously basing my opinions thus far on beta 1 and the publicly
released statements about changes for beta 2. I'll definitely be
re-evaluating after working with beta 2 for a while and after we see how
widely it is adopted after RTM. I doubt the majority of VB users have any
grasp yet how different it is going to be. I saw comments in the newsgroup
recently about how VB had changed fairly gradually over the years and that,
although they had not looked at it, "VB7" would probably be nothing
unexpected. I almost choked.
<cut>
> However, based on what I've seen so far, I am entirely convinced that
VB.NET
> is going to provide - by far - the easiest migration path for existing VB
> devs to move from Windows to .NET.
There I agree with you 100%
> And those devs WON'T have to learn OO programming to succeed.
Well.... VB users now can get away without using classes and without
understanding classes at all but I think the bar has been raised in VB.Net,
again mostly because of the intimidation factor. It may be that they could
hack something functional in VB.Net without learning OO basics but I don't
think they'll try given VB.Net as it stands today. I see them staying with
VB6 or moving to some other development tool. Again, depending on what MS
does with beta 2 and beyond this will change one way or the other.
> As an aside - if you are right, and for some reason VB devs move to VB.NET
> and then to C# - I think that the C-style community is in for a shock. It
> turns out that you can write code-behind-forms apps in C# too. You can
write
> C# apps without understanding classes and objects any more than VB devs to
> today. Anyone who assumes that the typical VB dev, who is productive
without
> classes, is going to become and OO programmer just by moving to C# has no
> grasp of reality.
Bad code can be done in any language. I look at VB.Net as the path MS
provides to get current VB users into the OO world -- generally familiar
syntax but a whole range of new features to learn. Once a non-OO VB user of
today is comfortable with an OO approach in VB.Net they can move to C# with
little effort. Moving a non-OO VB user directly into C# would hit them with
the double whammy of C syntax and OO concepts and anybody attempting to
learn the syntax without learning the design patterns first is bound to
produce some incredibly unmanageable code.
> IF the VB community moves to C#, we'll find that the _majority_ of C#
> programs at that point will be written without substantial or 'correct'
use
> of classes and objects, but instead rely heavily on code in forms and
direct
> use of data and all the things that VB devs do to be productive today.
I don't expect that at all. I expect that only VB developers who do have a
grasp of OO concepts and who utilize them as far as they can be taken in VB6
now will move to C#. As for the rest of the VB community, we'll see what
beta 2 looks like... they'll either move into VB.Net and produce the same
non-OO code and give VB.Net the same bad rap that VB6 has to many or move
off to something designed for the type of development they do.
> I am left wondering. If that DOES happen - and the C-rooted languages are
> overrun by highly productive and pragmatic VB devs - where will the
> elitist/purist devs go? Undoubtedly they'll view this whole thing as an
> abomination that has ruined their language. Will C# be looked down upon
just
> like VB is today?
<g>
> That's the problem with extremist ideology - when you DO manage to bring
the
> majority into your little clique you often find that your clique has been
> fundamentally changed into something you didn't anticipate - and _that_
gets
> messy. Fortunately an ideological 'war' in technology is somewhat safer
than
> the ones waged in the real world with guns and bombs...
yep. whatever happens, it's going to be an interesting ride for the next
few years.
Gregor R. Peisker
> As an aside - if you are right, and for some reason VB devs move to VB.NET
> and then to C# - I think that the C-style community is in for a shock. It
> turns out that you can write code-behind-forms apps in C# too. You can write
> C# apps without understanding classes and objects any more than VB devs to
> today. Anyone who assumes that the typical VB dev, who is productive without
> classes, is going to become and OO programmer just by moving to C# has no
> grasp of reality.
But they will use classes with static methods only, instead of modules. Doesn't this
count?
:-)
Regards,
Gregor
Larry Serflaten
"Bob Butler" <butl...@earthlink.net> wrote
> I'm just still too cynical to truly believe that VB.Net has a long-term
> future.
I'd say that if Basic was such a fundamentally poor language, it would have
been replaced by now...
LFS
Bob Butler
I'm not saying VB is a fundamentally poor language. I'm saying that MS is
maintaining two distinct languages with a very large overlap in target
market and that I expect them to phase 1 out over time and I expect that to
be VB.Net. I'm definitely not saying that's a good thing, just that I
expect it to happen.
Bob O`Bob
> Yes, there is a learning curve. We are getting a new version of VB - which
> always causes a learning curve (or at least did, back when a new version
> actually changed something - you know, vb 1->2->3->4 - the fact that vb 5
> and 6 are just big service packs doesn't count).
It's a minor point, but if that should end up quoted in history books
it would do the world a disservice.
Two->Three was "small potatoes" and had almost zero learning curve.
Getting a native code compiler and the ability to write many new types
of projects including OCX's (four->five) was most certainly a new version.
It was, in fact, a complete restart not even based upon VB4.
Bob
--
Kathleen Dollard
I gotta' just add this. Since you help us all remember that we are working
with _betas_ I was just thinking that for a beta this thing is pretty darn
approachable.
Rockford Lhotka
news:ek6xN0C8AHA.600@tkmsftngp04...
> But they will use classes with static methods only, instead of modules.
Doesn't this
> count?
>
> :-)
You see my point exactly :)
Rocky
Hans Blomme
> overlap in target market and that I expect them to phase 1 out over time
> and I expect that to be VB.Net.
I can't say that I really care about that. Once we all get to know .NET,
we'll know what assemblies we'll need to perform certain tasks, so... How
big can the step from VB.NET to -for example- C# be? It's just a few
syntax-changes... If your programming all day long, how long do you think
it'll take before you get to know the new syntax? I guess one or two weeks
max. And don't forget you'll still be programming all day long, it's not
like it _totally_ different, is it?
--
Hans Blomme
"Bob Butler" <butl...@earthlink.net> wrote in message
news:O6SXymD8AHA.1276@tkmsftngp03...
Bob Butler
> > I'm saying that MS is maintaining two distinct languages with a very
large
> > overlap in target market and that I expect them to phase 1 out over time
> > and I expect that to be VB.Net.
>
> I can't say that I really care about that. Once we all get to know .NET,
> we'll know what assemblies we'll need to perform certain tasks, so... How
> big can the step from VB.NET to -for example- C# be? It's just a few
> syntax-changes... If your programming all day long, how long do you think
> it'll take before you get to know the new syntax? I guess one or two weeks
> max. And don't forget you'll still be programming all day long, it's not
> like it _totally_ different, is it?
<g>
That's precisely the attitude that I think MS is hoping developers take.
Once they have moved into the dotnet world via VB.Net they have an
immediately available alternative in C# if/when support for VB.Net goes
away. As I said, I hope I'm wrong but that's what I'm reading between the
lines. At this point I'm just waiting for beta 2 of VS.Net to see where
things stand.
Thomas Banks
>maintaining two distinct languages with a very large overlap in target
>market and that I expect them to phase 1 out over time and I expect that to
>be VB.Net. I'm definitely not saying that's a good thing, just that I
>expect it to happen.
It's pretty obvious that VB.Net and C# are redundant. The sad fact is that MS
has lost sight of what VB is all about. Given the choice of making VB.Net a
natural extension of VB 6 or forcing all languages into the one-size-fits-all
.Net platform, they chose the latter.
There is no purpose for having both VB.Net and C# as languages other than the
ability to market the VB name to VB developers and C# to C/C++ developers.
It's tiresome to hear people claim that VB 6 had to be thrown out to become a
modern language. Features like threads and even OO don't force the language to
be incompatible with previous versions nor do they require the radical changes
to syntax that MS has made. These changes were made necessary only by MS's
insistence that VB fit like a glove in the .Net framework which is their latest
idea to extend their WinTel monopoly while fighting off pretenders to the
throne like Linux/Unix, Delphi and Java.
So, VB.Net superficially retains some of its syntax while stealing every idea
from Java MS can stuff into it. We get lip service to cross platform
compatiblity in the future which is just so much smoke in the air.
And MS will get away with it because they are so dominant in the industry.
Thomas Banks
MS has a track record of abandoning technologies and replacing them with new
ones as it struggles to compete in a trial and error fashion. It's even funny
to read books on previous versions of MS's tools -- say DAO -- sing it's
praises to now read them being trashed by cheerleaders promoting their latest
and greatest.
.Net is MS trying to compete on the Internet while maintaining a WinTel
monopoly. I don't see where .Net does much to make its development tools any
more competitive against competing Internet development products.
Sure, if you are a supporter of a world where you run Windows as a client,
Windows on the server, surf the web with Internet Explorer, etc. then .Net
almost makes sense. It integrates all languages in a common framework which
sits firmly upon the Windows API.
I say almost makes sense because the cost of the .Net framework, even in a 100%
MS world, is that it forces languages to fit into the .Net framework because
the framework lacks to flexibility to bend the other way. So, for example,
when you read MS's marketing materials on Pyton.Net you read about how they are
forced to alter the language to get it to fit.
So what happen if this experiment fails? They've already dumped the VB 6
community. So when the dump VB.Net and move onto the next Bill Gates vision
are all the cheerleaders going to embrace it with all the joy they seem to be
embracing all of MS's other .Net changes? It'll be amusing to watch.
Richard Curzon
comment anyway.
Maybe the order of language experiences affects one's view. I did
assembler, then a few line# basics, then C, then Smalltalk, and finally VB.
But the "revelation" of VB to me wasn't the builtin functions at all. They
look and feel exactly like functions from the old C libraries, who cares
what's builtin and what's #included.
The revelation for me was in making the compiler see what the human sees.
We can easily see the end of line, so the compiler does to. We like to see
prominent beginnings and endings, borders to things. So does the VB compiler
(not obscure curly braces etc.).
For the first hour in VB I was saying "what a waste of typing" "END IF"
instead of just "}". For the next 9 years I've been saying, it's almost
magical how much easier to the code is to read and write. Why shouldn't the
compiler come to the human instead of vice versa?
So when we we say
txtInput.Text.Trim.Length
instead of
Len(Trim$(txtInput.Text)
IMO,
a) absolutely nothing of the Basic essence is lost. It's equally easy to
read, in fact I think easier.
b) the stuff I call the Basic essence stands out more than ever. We are
playing on a level field with all the other dot net languages, and the
strengths of "making the compiler come to the person" will push VB (i.e.
improved Basic) to new heights.
regards
Richard
--
-----
Live without dead time - Raoul Vaneigem
May I borrow your towel, my car just hit a water buffalo - Chevy Chase
james
to be confusing and upsetting to me. Then I thought back to
the first time I used VB and then I remembered feeling the same way.
You know, "That's not how we did it in Quick Basic or PDS7 "......
But, now after using VB.NET Beta1 and chomping at the bit in antisipation of
Beta2 and the final release, I can hardly wait. That's not to say that I'm
100% comfortable with VB.NET , yet. But, I'm getting there.
james
"Richard Curzon" <s...@interNOSPAMlog.com> wrote in message
news:eXgH0zS8AHA.1576@tkmsftngp04...
Bruce L-C
track. There are millions of VB programmers. Given the power that VB.Net
has, if anything it will keep anyone who starts using it in the camp. You
can use it everywhere (behind web pages, in windows apps, etc) and it has
all the power of any other language.
I think the misconception people get is because with beta 1 so many of the
examples were in C#, not in VB. Wait until beta 2, I am guessing that there
will be many more VB examples (indeed there are statements from MS that this
will be the case).
VB is very strategic to MS. Since it uses the same IDE, the same framework
etc, it is not like it is a huge issue to keep it going. VB programmers are
MS ace in the hole when competing against Java. C# is to appeal to C++ and
Java programmers.
Now it is a valid argument on whether MS will pull its VB programmers with
it, but whether it is important to MS is beyond question.
If anything, I think the argument can go the other way, any language but
VB.Net will be the marginal language. VB.Net will be THE language of DotNet.
Bruce L-C
Bob Butler
news:eAeZlKd8AHA.1456@tkmsftngp05...
<cut>
> VB.Net will be THE language of DotNet.
You may be right with some of your points, but that last is simply wrong.
C# is THE language for dotnet. It's the natural choice for C++ developers
and VB.Net is always going to be a second-class language to the programmers
at MS no matter what the marketing types say.
Hans Blomme
VB.NET ... (but please don't make me find a reference ;-)
--
Hans Blomme
"Bob Butler" <butl...@earthlink.net> wrote in message
news:uZLPfQd8AHA.1932@tkmsftngp04...
JP Hamilton
--JP
"Thomas Banks" <tba...@aol.comnospam> wrote in message
news:20010609131138...@ng-fh1.aol.com...
Bob Butler
> As far as I know, Microsoft did confirm that C# is more powerfull than
> VB.NET ... (but please don't make me find a reference ;-)
C# can use unsafe and/or unmanaged code (I keep getting those two confused
and don't remember if it's one or the other or both offhand) but for the
most part it's not the actual "power" that makes C# the premier language,
it's the perceived power that the C fmaily has over the Basic family. MS
does a heck of a lot more with C++ now than they do with VB and I can't see
them moving their C++ developers into VB.Net. I can see them moving into C#
development and if it does come time to make a choice between supporting C#
and VB.Net they'll have to go with where their investment is and that's C#
coding. What their customer base uses will be secondary.
Rockford Lhotka
But how do we decide what is THE language?
VB today is THE language for programming Windows. Why do I say that? Because
VB devs outnumber C++ devs 3 to 1.
Odds are that will continue in .NET.
So, for C# to be THE language for .NET we're going to need a LOT of people
switching from VB. I doubt that many will switch - not by a long shot.
Aaron Anderson
with VB. If the market goes the orher way, C# won't be too hard to learn.
After all, it's the BCL and conceps that take most of the learning, not the
syntax.
"Rockford Lhotka" <ro...@lhotka.net> wrote in message
news:ufa6Clh8AHA.2016@tkmsftngp03...
Privlin Merck
By the way, can any of you Microsoft geniuses justify the system
variable change in SQL2000 from suser_name to suser_sname. When you
deprecate elements, please have a damn good reason for doing so...it's
make-work, and it makes me sick...
Former DAO, RDO, ADO, JetDirect, ODBCDirect, OLEDB ...junkie...
Privlin Merck
tba...@aol.comnospam (Thomas Banks) wrote in message news:<20010609132652...@ng-fh1.aol.com>...
Bob Butler
<cut>
> VB today is THE language for programming Windows. Why do I say that?
Because
> VB devs outnumber C++ devs 3 to 1.
>
> Odds are that will continue in .NET.
>
> So, for C# to be THE language for .NET we're going to need a LOT of people
> switching from VB. I doubt that many will switch - not by a long shot.
I don't see the absolute numbers as mattering very much. If MS developers
use C# for development then that's the language with a future.
Bob O`Bob
>
> I've been back and forth many times myself, but basically decided to stick
> with VB. If the market goes the orher way, C# won't be too hard to learn.
Well said:
If the market goes the orher way, C# won't be too hard to learn.
Of course, my primary choice is dramatically different from yours,
but discussing that wouldn't be appropriate in this group.
Bob O`Bob
--
Joe "Nuke Me Xemu" Foster
> "Rick Barnett" <ri...@dbmv.com> wrote in message
> news:#czgCN67AHA.1980@tkmsftngp03...
> <cut>
> > VB.NET will justify itself, even if only through ASP.NET and VSA in
> Office.
>
> Interesting. VSA in office is something I expect to fail big time. Most
> Office VBA developers I've ever seen don't handle VBA's OO capabilities now
> and I expect they'll really dislike VSA.
I've seen precious few class modules in VBA that I didn't author. Of course
this is mere anecdotal evidence and MUST therefore be dismissed out of
hand, unless said anecdotal evidence supports the .NET jocks... Hip, hip,
hooray for VSA.NET, which will finally put all those contemptible wussie
macro coders their place, at the tender mercies of the OOP Masters! Feh.
Of course, by not leaping onto the .NET bandwagon to join the jocks, I have
merely revealed that I "likely" "can't cope with vb.net", an "irrefutable"
Truth "Straight Outta Redmond", no matter what proficiency in OOP I may
already have demonstrated! Keep up or die, and never mind whether "keeping
up" in the .NET migration death-march is even desirable or wise.
> > The reason I credit Sun is that Java has become such a large influence
> > outside of Windows, it seems likely to lift C# in .NET as shops look to
> > standardize on that class of tools. VB.NET is the odd boy out.
>
> I don't disagree, but I still think offering the "odd boy out" to people who
> dislike Java or C-style coding makes sense and gives VB.Net a bit of a
> reason to exist. I just don't think it's enough to offset the cost of
> maintaining both VB.Net and C# in the long term.
Not even as a macro preprocessor to C#? The squinters at squiggles have won
at last! =( Too bad they won by killing VB instead of by giving us a better
VC++. >=(
--
Joe Foster <mailto:jfo...@ricochet.net> DC8s in Spaace: <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!
Joe "Nuke Me Xemu" Foster
Irrelevant! What Microsoft's other divisions want, Microsoft's other
divisions get, and it is incumbent upon us to bow and scrape in ecstatic
gratitude that we're given the rare privilege to use Microsoft-developed
development tools at all, you unappreciative morons. =P
--
Joe Foster <mailto:jfo...@ricochet.net> "Regged" again? <http://www.xenu.net/>
Joe "Nuke Me Xemu" Foster
> "what is the essence of VB", potential fruitless war here... <g> but let's
> comment anyway.
>
> Maybe the order of language experiences affects one's view. I did
> assembler, then a few line# basics, then C, then Smalltalk, and finally VB.
>
> But the "revelation" of VB to me wasn't the builtin functions at all. They
> look and feel exactly like functions from the old C libraries, who cares
> what's builtin and what's #included.
You will have to care in B#!
> The revelation for me was in making the compiler see what the human sees.
> We can easily see the end of line, so the compiler does to. We like to see
> prominent beginnings and endings, borders to things. So does the VB compiler
> (not obscure curly braces etc.).
>
> For the first hour in VB I was saying "what a waste of typing" "END IF"
> instead of just "}". For the next 9 years I've been saying, it's almost
> magical how much easier to the code is to read and write. Why shouldn't the
> compiler come to the human instead of vice versa?
>
> So when we we say
>
> txtInput.Text.Trim.Length
>
> instead of
>
> Len(Trim$(txtInput.Text)
>
> IMO,
>
> a) absolutely nothing of the Basic essence is lost. It's equally easy to
> read, in fact I think easier.
>
> b) the stuff I call the Basic essence stands out more than ever. We are
> playing on a level field with all the other dot net languages, and the
> strengths of "making the compiler come to the person" will push VB (i.e.
> improved Basic) to new heights.
Now add a ReallyCoolConvenienceFunction, taking a String and returning a
String, in both VB and B#. You might get:
ReallyCoolConvenienceFunction(txtInput.Text.Trim).Length
instead of
Len(ReallyCoolConvenienceFunction(Trim$(txtInput.Text))
Now which is easier to read? These are the new heights? Or should adding
new functions be left for the Real Programmers within Microsoft? Must we
derive a new class from String to which we can add our new function as a
method in an effort to preserve the "flow" when attempting to call it?
This is progress? Are you sure about that?
--
Joe Foster <mailto:jfo...@ricochet.net> Space Cooties! <http://www.xenu.net/>
JP Hamilton
Joe "Nuke Me Xemu" Foster
> You can't derive from String. Its NotInheritable:)
So what can be done to avoid this sort of step to the right, jump to the
left, let's do the time-warp again? >=)
--
Joe Foster <mailto:jfo...@ricochet.net> On the cans? <http://www.xenu.net/>
Richard Curzon
MS has done a pretty good job for the first pass at CLR.
For example, there is an Array object, and an operation frequently done on
arrays is BinarySearch. So, BinarySearch is a method of the Array class.
I find the natural methods I've hoped to find so far, MS thought of them.
If you have a ReallyCoolOperation that MS didn't think of but is pretty
general, you should bring it up as a suggestion to MS. Or maybe, rethink it
yourself.
E.g., I saw the need to have an operation that wrapped a string in XML/HTML
tags. I.e., it would insert the begin version at offset A in the string
"<TR>", the end version at offset B "</TR>", and indent all the lines
inbetween (add a tab before each CRLF). Without the overheads of checking
for buffer overruns for each insertion etc, which CLR is going to do whether
I want it or not.
Now I could say to MS, class String sucks because it doesn't have this
capability...
They'd probably say back to me, this is properly a feature of XML DOM, and
you should use that tool. And if XML DOM is too slow, that's a problem you
should bring up to over there, with those guys, go away. Ok catch 22.
In the meantime, I might
a) write a function like in VB6
b) write a class that delegates to String,
c) write a class that delegates to lower level structures like byte arrays
and translates to/from String,
d) write a C++ object with CLR hooks, where I control overrun checks and
reallocation
e) inherit from String
OOPS... can't do (E)! That's the only one I can't do. And rightly so IMO.
<g>
The most experienced Smalltalkers are much more reluctant than the newbies
for everyone to start creating their own version of String, it really
muddies up the language and interferes with code reuse and discussion. I
think that's why so many classes in CLR are not inheritable. And I agree,
IMO you should use one of the other ways.
You can build your own separate class libraries, and probably will. But it
won't be for penny ante stuff like ReallyCoolMethod, it'll be specialized
app framework stuff IMO.
regards
Richard.
Joe "Nuke Me Xemu" Foster
> Since you ask ...
>
> MS has done a pretty good job for the first pass at CLR.
They just didn't do a good job of VB.NET, is all.
> For example, there is an Array object, and an operation frequently done on
> arrays is BinarySearch. So, BinarySearch is a method of the Array class.
>
> I find the natural methods I've hoped to find so far, MS thought of them.
>
> If you have a ReallyCoolOperation that MS didn't think of but is pretty
> general, you should bring it up as a suggestion to MS. Or maybe, rethink it
> yourself.
As in, StrReplaceAll and InStrLast for VB3, Split for VB4, etc...? At
least, those nice general functions, once included in the project as
a shared module, integrated well with the built-ins without too much
jumping through hoops.
> E.g., I saw the need to have an operation that wrapped a string in XML/HTML
> tags. I.e., it would insert the begin version at offset A in the string
> "<TR>", the end version at offset B "</TR>", and indent all the lines
> inbetween (add a tab before each CRLF). Without the overheads of checking
> for buffer overruns for each insertion etc, which CLR is going to do whether
> I want it or not.
>
> Now I could say to MS, class String sucks because it doesn't have this
> capability...
OTOH, if you could provide the capability yourself as a nice generic
component that has little "cognitive friction" with the rest of the
development environment, perhaps what would suck worse would be MSFT's
doing it instead of providing something that we couldn't do ourselves,
like the ability to create plain old Win32 DLLs.
> They'd probably say back to me, this is properly a feature of XML DOM, and
> you should use that tool. And if XML DOM is too slow, that's a problem you
> should bring up to over there, with those guys, go away. Ok catch 22.
>
> In the meantime, I might
> a) write a function like in VB6
And deal with the resulting cognitive friction. Oh sure, it's only a
little thing, like a mosquito around our ears...
> b) write a class that delegates to String,
> c) write a class that delegates to lower level structures like byte arrays
> and translates to/from String,
> d) write a C++ object with CLR hooks, where I control overrun checks and
> reallocation
> e) inherit from String
>
> OOPS... can't do (E)! That's the only one I can't do. And rightly so IMO.
> <g>
I suppose I should be grateful that the hoops aren't actually aflame...
This is progress?
> The most experienced Smalltalkers are much more reluctant than the newbies
> for everyone to start creating their own version of String, it really
> muddies up the language and interferes with code reuse and discussion. I
> think that's why so many classes in CLR are not inheritable. And I agree,
> IMO you should use one of the other ways.
>
> You can build your own separate class libraries, and probably will. But it
> won't be for penny ante stuff like ReallyCoolMethod, it'll be specialized
> app framework stuff IMO.
What hoops must I jump through to get such libraries to interoperate
with Microsoft's? Will the Convert magic work only with built-in types?
Don't you know that methods break encapsulation anyway? Forget methods,
unless you're authoring a class and need protected virtual methods, for
the overloaded friend functions and subs which other components can use
to interact with the classes. Note that not all those overloads need to
be friends. And as for f(x, y, z) vs. x.f(y, z), the classic distinction
without a difference... Overhead? In a world with "inline"?
JP Hamilton
these libraries to accomplish what we need done.
--JP
"Joe "Nuke Me Xemu" Foster" <j...@bftsi0.UUCP> wrote in message
news:eCpH1Mr8AHA.2068@tkmsftngp03...
Joe "Nuke Me Xemu" Foster
> Then again there is this thing called "programming" that we can all use with
> these libraries to accomplish what we need done.
Did you actually read what I wrote? It can't be possible, or is attempting
to extend these libraries not considered "programming" on your home planet?
--
Joe Foster <mailto:jfo...@ricochet.net> Got Thetans? <http://www.xenu.net/>
JP Hamilton
all of the functionality you wanted for strings was already in
System.String. I wasn't sure why exactly you needed "plain old" DLL's
instead of an assembly. And I wasn't quite sure what your point on Convert
was about, because that class is used for conversions involving base
types...and as far as I can tell MS has covered that pretty well. You are
free to write your own conversion routines if they are applicable to your
problem domain and ToString can be overridden.
As far as the String thing, you could use containment. Not always pretty,
but a valid option nonetheless. Anyway, allowing people to extend a String
is not such a good idea. Consider the performance cost of that. Im sure it
violates a heuristic or two in regards to OOP. God classes and such. There
are several reason...search the DOTNET list archives.
--JP
"Joe "Nuke Me Xemu" Foster" <j...@bftsi0.UUCP> wrote in message
news:uVeOtrr8AHA.408@tkmsftngp05...
Thomas Banks
Yes, I've fiddled with Beta 1. I've also gone through much of "VB.Net
Programming With the Public Beta."
I've pretty much put down Beta 1 for now in hopes Beta 2 is a marked
improvement. At work, we're reevaluating our commitment to VB though I'm not
personally involved in that effort.
Joe "Nuke Me Xemu" Foster
> Yes I did read what you wrote. The first thing I noticed was the fact that
> all of the functionality you wanted for strings was already in
Those were examples of things I had to do on my own for previous versions.
Sure, VB.NyET has built-ins for them now, but Microsoft can't be expected
to provide everything in B# 1.0, can they? You can write a function (AKA
"programming"), but unlike the built-ins, you must forevermore remember
that using it is quite different from using the functions that Microsoft
saw fit to bestow upon us Great Unwashed.
> System.String. I wasn't sure why exactly you needed "plain old" DLL's
> instead of an assembly. And I wasn't quite sure what your point on Convert
> was about, because that class is used for conversions involving base
> types...and as far as I can tell MS has covered that pretty well. You are
> free to write your own conversion routines if they are applicable to your
> problem domain and ToString can be overridden.
Yet Rudolph the red-nosed class still won't be allowed to play the MSFT
games... As far as Convert goes, it was the wrong approach. A better way
would have been to use overloaded functions. Let's look at ToString,
though let's postulate the existence of a VB7 which supports overloading:
Public Function CStr(Expression As Rudolph) As String
CStr = "<rudolph><lumens>" & Expression.Nose & "</lumens></rudolph>"
End Function
What! Isn't CStr a built-in? Yes, and we should be able to override it,
especially in situations where the built-ins would cough up a "compile
error: type mismatch" anyway.
> As far as the String thing, you could use containment. Not always pretty,
> but a valid option nonetheless. Anyway, allowing people to extend a String
> is not such a good idea. Consider the performance cost of that. Im sure it
> violates a heuristic or two in regards to OOP. God classes and such. There
> are several reason...search the DOTNET list archives.
So Microsoft may extend their classes, but we may not? As a counter-example,
allow me to present C++'s stream classes. You can derive from them as much
as you like, with little or no performance hit, since there are only *two*
virtual methods, and the other methods are mere glorified macros! So, just
because MSFT couldn't figure out how to design an extensible class library
without sacrificing performance doesn't mean it's impossible.
--
Joe Foster <mailto:jfo...@ricochet.net> Sign the Check! <http://www.xenu.net/>
MS NET
that MS
> has lost sight of what VB is all about.
I believe the sad fact is someone doesn't seem to know a whole lot about
either language..........
"Thomas Banks" <tba...@aol.comnospam> wrote in message
news:20010609131138...@ng-fh1.aol.com...
> >I'm not saying VB is a fundamentally poor language. I'm saying that MS
is
> >maintaining two distinct languages with a very large overlap in target
> >market and that I expect them to phase 1 out over time and I expect that
to
> >be VB.Net. I'm definitely not saying that's a good thing, just that I
> >expect it to happen.
>
Kathleen Dollard
You seem intelligent, so let's be sure your underlying information is
correct so that your conclusions are insightful or at least bear some
resemblance to reality.
> Sure, if you are a supporter of a world where you run Windows as a client,
> Windows on the server, surf the web with Internet Explorer, etc. then .Net
> almost makes sense. It integrates all languages in a common framework
which
> sits firmly upon the Windows API.
Where did you get this? MS supplies tools at all these levels, but that does
not mean you have to use those tools. They are deliberately and explicitly
opening up the ballgame to anyone who wants to play. You can use a Windows
client through a Webservice to a non-MS solution and is working for a W3C
standard here. XML is a underlying data structure that you can retrieve
directly from SQLServer. Web forms are designed to produce HTML runable in
any browser. And that doesn't eventougch that the CLS spec is open so other
people can write runtimes and languages.
On what basis do you state the above?
> So what happen if this experiment fails? They've already dumped the VB 6
> community. So when the dump VB.Net and move onto the next Bill Gates
vision
> are all the cheerleaders going to embrace it with all the joy they seem to
be
> embracing all of MS's other .Net changes? It'll be amusing to watch.
To determine whether the experiment failed, you have to ascertain that it is
an experiment and what it is trying to show.
But if your point is whether VB.Net will fail, then the answer is yes. The
answer is yes as surely as you will die one day. Products, all products,
have a life cycle. You will probably not be writing in VB.Net in 10 years.
Very, very few people have been writing in VB for 10 years (although all six
of them are probably here and will chime in).
The question then is whether you can get a good product cycle out of the
tool. I think a key aspect of that is to reduce product development cycles.
Since I think VB.Net will do this, then I think it is a great step forward.
It also further supports componentized applications which allow development
cycle to occur in a phase wise manner. Instead of some disruptive monster
app replacement, individual pieces can be replaced (in dotnet and/or the
next technology) and business decisions on in-house programming updated
happen in an intelligent manner.
Let me be clearer. I am currently deploying a 3 year old application. Yes,
that is right. Initial deployment, three year old application. Rarely have I
seen initial deployment of reasonable size apps take less than 18 months,
which is completely unacceptable from a business perspective. That is the
problem that dotnet improves on by one little increment. I look forward to
dotnet, and to the next little increment and the next.
You are in an industry of change. If you don't like change, this isn't the
right business for you. I don't know whether we will ever get an adequate
language that we can program in for a very long time. Nice as VB6 was, it
was not that language. I don't like everything in dotnet. I am still furious
Integer and arrays. It was one step backwards and two steps forward in terms
of actual application development, IMO. I notice acutely the one step
backwards. But it is also a net step forward.
--
Kathleen
(MS-MVP)
Reply in the newsgroup so everyone can benefit
--
Kathleen Dollard
Why do you refer to cognitive dissonance in relation to this
> Now add a ReallyCoolConvenienceFunction, taking a String and returning a
> String, in both VB and B#. You might get:
>
> ReallyCoolConvenienceFunction(txtInput.Text.Trim).Length
>
> instead of
>
> Len(ReallyCoolConvenienceFunction(Trim$(txtInput.Text))
To me that first one looks really lovely. I read left to right instead of
seeing the function called and working out.
Interested in why you think the second is preferable. I have enough respect
for you that I don't think it is just familiarity.
Joe "Nuke Me Xemu" Foster
> Joe,
>
> Why do you refer to cognitive dissonance in relation to this
>
> > Now add a ReallyCoolConvenienceFunction, taking a String and returning a
> > String, in both VB and B#. You might get:
> >
> > ReallyCoolConvenienceFunction(txtInput.Text.Trim).Length
> >
> > instead of
> >
> > Len(ReallyCoolConvenienceFunction(Trim$(txtInput.Text))
>
> To me that first one looks really lovely. I read left to right instead of
> seeing the function called and working out.
>
> Interested in why you think the second is preferable. I have enough respect
> for you that I don't think it is just familiarity.
Respect? I figured my bridges with DevX people must surely burn with
thermonuclear fire by now, especially after my complete and total lack
of "significant contribution" there! For starters, the eye must jump
around more on the first example, since some functionality will be
"inside" and other "outside" the classes. Why, if the only difference
between "inside" and "outside" is whether Microsoft may have forgotten
something? For just my example, it's no big deal, but things can get
out of hand rather quickly. I'd also be perfectly happy with
txtInput.Text.Trim.ReallyCoolConvenienceFunction.Length if I could get
it, and I've babbled more than once about a way in which we could get
it without jumping though hoops. The nice thing about plain old subs
functions is that we didn't have to constantly be aware of what comes
from Microsoft and what comes from elsewhere, unless we *wanted* to.
Perhaps that would make things a little too easy, and only janitors
care about easy, never the "keep up or die" programming jocks. The
inmates are running the asylum!
--
Joe Foster <mailto:jfo...@ricochet.net> Got Thetans? <http://www.xenu.net/>
Rockford Lhotka
True in a sense. But it doesn't hold to up historical precedent.
Over the past decade we've watched the MS devs use C++ for development - yet
VB has been the language of choice for Windows development. Why wasn't C++
the 'language with a future'?
If it didn't work before, why do we expect that it will work now? I do
believe you could argue that it will work now because C# is just VB with
semi-colons - but that is trite. :)
Joe "Nuke Me Xemu" Foster
> "Bob Butler" <butl...@earthlink.net> wrote in message
> news:u$t1IVi8AHA.1716@tkmsftngp03...
> > I don't see the absolute numbers as mattering very much. If MS developers
> > use C# for development then that's the language with a future.
>
> True in a sense. But it doesn't hold to up historical precedent.
>
> Over the past decade we've watched the MS devs use C++ for development - yet
> VB has been the language of choice for Windows development. Why wasn't C++
> the 'language with a future'?
>
> If it didn't work before, why do we expect that it will work now? I do
> believe you could argue that it will work now because C# is just VB with
> semi-colons - but that is trite. :)
Fine. B# is C# with a preprocessor. >=)
--
Joe Foster <mailto:jfo...@ricochet.net> DC8s in Spaace: <http://www.xenu.net/>
Hans Blomme
--
Hans Blomme
"Joe "Nuke Me Xemu" Foster" <j...@bftsi0.UUCP> wrote in message
news:O5sK7O38AHA.1256@tkmsftngp05...
Hans Blomme
> right, or right to left. You have to mix it up.
To me te problem is that sometimes there are too many '(' and ')' which
makes it (a little) harder to read.
> I hate both. If I had to choose, though, I'd pick the second as
> better.
I would pick the first one.
--
Hans Blomme
"Craig C" <chc...@nospam.please> wrote in message
news:8rrcitkdt90v7mmu2...@4ax.com...
> Hi Kathleen,
>
> >> ReallyCoolConvenienceFunction(txtInput.Text.Trim).Length
> >>...
> >> Len(ReallyCoolConvenienceFunction(Trim$(txtInput.Text))
> >
> >To me that first one looks really lovely. I read left to right instead of
> >seeing the function called and working out.
>
> The problem (with both, really) is that you can not read left to
> right, or right to left. You have to mix it up.
>
> Ideally, the order of operations should flow in one of two directions.
>
> A->B->C->D->E
> or
> A<-B<-C<-D<-E
>
> However, the functions above map like this:
>
> (A<-(B->C->D)->E
> and
> A<-B<-C<-(D->E)
>
> I hate both. If I had to choose, though, I'd pick the second as
> better. At least it has only one misdirection. With the first, I have
> to balance the parentheses in order to figure out where .Length
> applies.
>
> For keeping code readable, I will certainly push a standard that says
> that if you misdirect the operational order, you should push into
> separate lines:
>
> Dim sTemp As String
>
> sTemp = txtInput.Text.Trim
> sTemp = ReallyCoolConvenienceFunction(sTemp)
> sTemp = sTemp.Length
>
> At least here I can read it without going to the middle, reading
> right, pushing back left, and back to the right again.
>
> Ciao, Craig
>
bobJ
"Hans Blomme" <hans....@yucom.be> wrote in message
news:#7Or7l38AHA.2096@tkmsftngp02...
> > The problem (with both, really) is that you can not read left to
> > right, or right to left. You have to mix it up.
>
> To me te problem is that sometimes there are too many '(' and ')' which
> makes it (a little) harder to read.
>
> > I hate both. If I had to choose, though, I'd pick the second as
> > better.
>
> I would pick the first one.
>
BobJ
Joe "Nuke Me Xemu" Foster
> > The problem (with both, really) is that you can not read left to
> > right, or right to left. You have to mix it up.
>
> To me te problem is that sometimes there are too many '(' and ')' which
> makes it (a little) harder to read.
>
> > I hate both. If I had to choose, though, I'd pick the second as
> > better.
>
> I would pick the first one.
How about Reverse Polish Notation, a la Forth? >=)
txtInput Text Trim ReallyCoolConvenienceFunction Length
--
Joe Foster <mailto:jfo...@ricochet.net> "Regged" again? <http://www.xenu.net/>
Hans Blomme
That's exactly my point.
--
Hans Blomme
"bobJ" <bobj...@hotmail.com> wrote in message
news:uzWsJu38AHA.1920@tkmsftngp04...
Bob Butler
<cut>
> Over the past decade we've watched the MS devs use C++ for development -
yet
> VB has been the language of choice for Windows development. Why wasn't C++
> the 'language with a future'?
>
> If it didn't work before, why do we expect that it will work now? I do
> believe you could argue that it will work now because C# is just VB with
> semi-colons - but that is trite. :)
Not so much "VB with semicolons" but C# is, I believe, more accessible to a
broader audience than C++. VB targeted a lower-end developer and/or quicker
development (broad generalization there I realize) and had a target audience
who would not use C++ as an alternative.
If the choice between C# and VB.Net truly becomes primarily syntax
preference with no significant difference in capabilities then I'm still at
a loss as to why MS would invest the resources long-term in developing and
supporting both.
Hans Blomme
> that if you misdirect the operational order, you should push into
> separate lines:
>
> Dim sTemp As String
>
> sTemp = txtInput.Text.Trim
> sTemp = ReallyCoolConvenienceFunction(sTemp)
> sTemp = sTemp.Length
>
> At least here I can read it without going to the middle, reading
> right, pushing back left, and back to the right again.
Dim iTemp as Integer
sTemp = ReallyCoolConvenienceFunction(sTemp)
--
Hans Blomme
JP Hamilton
"Hans Blomme" <hans....@yucom.be> wrote in message news:ur09OO58AHA.2204@tkmsftngp02...
Joe "Nuke Me Xemu" Foster
> If the choice between C# and VB.Net truly becomes primarily syntax
> preference with no significant difference in capabilities then I'm still at
> a loss as to why MS would invest the resources long-term in developing and
> supporting both.
Especially when they *could* have instead put the effort into VB7, even
as a transition product with real deprecation, and something truly Cool?
Or is B# supposed to be Cool and C# to be J#?
--
Joe Foster <mailto:jfo...@ricochet.net> On the cans? <http://www.xenu.net/>
Joe "Nuke Me Xemu" Foster
> Then again, there is always:
>
> Public Class NukeMeXemuString
> Private s As String
>
> Public Sub New(myString As String)
> s = myString.Trim()
> End Sub
>
> Public Function ReallyCoolFunction() As String
> 'Do something remarkable and return the result
> End Function
>
> Public ReadOnly Property Length
> Get
> Return s.Length
> End Get
> End Property
>
> End Class
I suppose if everything's now an object, and modules are now "static
global classes", this might be what I'd have to do anyway. However, what
does our hypothetical one-liner now look like?
txtInput.Text.Trim.???.ReallyCoolConvenienceFunction.Length
I believe I have a possible candidate for what a really cool convenience
function might actually do: return the Double Metaphone "phonetic hash"
code. There's an article at http://www.cuj.com/ about Double Metaphone,
but I don't know how they feel about "deep links". Does this help those
of you who seem uncomfortable discussing mere airy-fairy abstractions?
Joe "Nuke Me Xemu" Foster
> For keeping code readable, I will certainly push a standard that says
> that if you misdirect the operational order, you should push into
> separate lines:
>
> Dim sTemp As String
>
> sTemp = txtInput.Text.Trim
> sTemp = ReallyCoolConvenienceFunction(sTemp)
> sTemp = sTemp.Length
Better make sTemp a Variant, I mean, an Object...
--
Joe Foster <mailto:jfo...@ricochet.net> DC8s in Spaace: <http://www.xenu.net/>
Kathleen Dollard
> Respect? I figured my bridges with DevX people must surely burn with
> thermonuclear fire by now, especially after my complete and total lack
> of "significant contribution" there!
Well, I was under the impression that bridges burned by those retreating.
Are you planning a retreat?
> For starters, the eye must jump
> around more on the first example, since some functionality will be
> "inside" and other "outside" the classes.
Well, like all of us I am still learning, so I appreciate your explanation.
I suppose if ReallyCoolConvenienceFunction is a little utility that I don't
want to have to think about, along the lines of trim, then I would agree. If
it is something that _should_ have been in the class. But in that case I am
likely to put it in the class.
Generally I will care what I am doing, with the interesting stuff in the
function and its parameters and as my mind becomes bored reading toward the
end of the line, I can drift off. It is the stuff not in class that I expect
to be of more interest to me. Of course that does leave one reading
noun/verb verb/noun in the following (notice how I finesse the use of
Hungarian and the possibity of a type issue by completely obscure and
meaningless variable names
x1 = AllicesRestaurant.DumpGarbage
x2 = ReallyCoolConvenienceFunction(txtInput.Text.Trim).Length
I like the rhythm in that, but I can see why some might dislike it. I do
dislike your VBClassic example though. Too many parens to track.
Joe "Nuke Me Xemu" Foster
> Joe,
>
> > Respect? I figured my bridges with DevX people must surely burn with
> > thermonuclear fire by now, especially after my complete and total lack
> > of "significant contribution" there!
>
> Well, I was under the impression that bridges burned by those retreating.
> Are you planning a retreat?
No, I was thinking of the old "don't burn your bridges" adage. Or is
there some additional verbiage of which I'm unaware, perhaps like the
rest of "my country, right or wrong" or "may you live in interesting
times"? Anyway, bridges are also burned by those attacking, perhaps
by napalm or fuel-air bombs. Not that I'm claiming to be da bomb! The
bomb lives only as it is falling. (Iain Banks?)
> > For starters, the eye must jump
> > around more on the first example, since some functionality will be
> > "inside" and other "outside" the classes.
>
> Well, like all of us I am still learning, so I appreciate your explanation.
> I suppose if ReallyCoolConvenienceFunction is a little utility that I don't
> want to have to think about, along the lines of trim, then I would agree. If
> it is something that _should_ have been in the class. But in that case I am
> likely to put it in the class.
How can you put it in String? How can I remedy String's *shocking* lack
of Soundex, Metaphone, and DoubleMetaphone methods? =)
> Generally I will care what I am doing, with the interesting stuff in the
> function and its parameters and as my mind becomes bored reading toward the
> end of the line, I can drift off. It is the stuff not in class that I expect
> to be of more interest to me. Of course that does leave one reading
> noun/verb verb/noun in the following (notice how I finesse the use of
> Hungarian and the possibity of a type issue by completely obscure and
> meaningless variable names
>
> x1 = AllicesRestaurant.DumpGarbage
> x2 = ReallyCoolConvenienceFunction(txtInput.Text.Trim).Length
>
> I like the rhythm in that, but I can see why some might dislike it. I do
> dislike your VBClassic example though. Too many parens to track.
You don't Lisp? I'm shocked, *shocked*! Anyway, often there's simply no
escape from parens, since methods and Property Gets often also require
parameters. What then, Forth.NET? I wonder how that might work...
Hans Blomme
--
Hans Blomme
"JP Hamilton" <jp...@swbell.net> wrote in message news:u4WWdo58AHA.408@tkmsftngp05...
Hans Blomme
happen to know how, and my boss just happens to pay me for doing so. If he'd
rather pay me for writing C#, no problem, I'll switch!
--
Hans Blomme
"Bob Butler" <butl...@earthlink.net> wrote in message
news:uh7KoHG8AHA.1408@tkmsftngp07...
> "Hans Blomme" <hans....@yucom.be> wrote in message
> news:#kA$96F8AHA.492@tkmsftngp04...
> > > I'm saying that MS is maintaining two distinct languages with a very
> large
> > > overlap in target market and that I expect them to phase 1 out over
time
> > > and I expect that to be VB.Net.
> >
> > I can't say that I really care about that. Once we all get to know .NET,
> > we'll know what assemblies we'll need to perform certain tasks, so...
How
> > big can the step from VB.NET to -for example- C# be? It's just a few
> > syntax-changes... If your programming all day long, how long do you
think
> > it'll take before you get to know the new syntax? I guess one or two
weeks
> > max. And don't forget you'll still be programming all day long, it's not
> > like it _totally_ different, is it?
>
> <g>
> That's precisely the attitude that I think MS is hoping developers take.
> Once they have moved into the dotnet world via VB.Net they have an
> immediately available alternative in C# if/when support for VB.Net goes
> away. As I said, I hope I'm wrong but that's what I'm reading between the
> lines. At this point I'm just waiting for beta 2 of VS.Net to see where
> things stand.
>
>
>
Joe "Nuke Me Xemu" Foster
> Then again, I don't really really really want to write VB-code...! I just
> happen to know how, and my boss just happens to pay me for doing so. If he'd
> rather pay me for writing C#, no problem, I'll switch!
Bleah. I'm done with squinting at squiggles. Maybe that was the thing to
do during the 60's and 70's, but we have better drugs now. =^)
bobJ
or die!
BobJ
"Joe "Nuke Me Xemu" Foster" <j...@bftsi0.UUCP> wrote in message
Hans Blomme
--
Hans Blomme
"Joe "Nuke Me Xemu" Foster" <j...@bftsi0.UUCP> wrote in message
news:#3SZGVC9AHA.2120@tkmsftngp07...
Rockford Lhotka
> If the choice between C# and VB.Net truly becomes primarily syntax
> preference with no significant difference in capabilities then I'm still
at
> a loss as to why MS would invest the resources long-term in developing and
> supporting both.
And I see your point here entirely.
The reason they might do that is if the developer community doesn't unite
under the banner of one language or the other.
Why do they still support FoxPro? Because there are 1.5 million users of the
product and thus it remains viable.
All C# has to do is keep 1.5 million developers loyal to the semi-colon and
it won't get rolled over by VB.NET ;)
Rocky
Joe "Nuke Me Xemu" Foster
> What I tried to say is: I love to learn and improve...
Oh, so do I, but I love to learn and improve... VB! Sadly, even though
the LazyString idea might not port as well to VB Classic as it does to
B#, (has anyone tried it?) other ideas, such as destroying some objects
in an asynchronous worker thread, do seem to have potential in VB. The
now-abandoned ClassAssist product has shown that effective inheritance
can be done via an add-in, even in VB4, without breaking anything!
Joe "Nuke Me Xemu" Foster
What do millions of VB developers have to do to keep from getting rolled
over by B#? Loyalty alone doesn't seem to be enough!
--
Joe Foster <mailto:jfo...@ricochet.net> Space Cooties! <http://www.xenu.net/>
Domenic Albano
Thats not entirely true, Class Assist simulated inheritance. But it wasn't
truly inheritance.
"Joe "Nuke Me Xemu" Foster" <j...@bftsi0.UUCP> wrote in message
news:e2XszvD9AHA.2044@tkmsftngp03...
Bob Butler
> Why do they still support FoxPro? Because there are 1.5 million users of
the
> product and thus it remains viable.
As I've said, I'm hoping I'm wrong, I'm just too cynical to think otherwise
<g>
I'm not a FoxPro user but from what little I know about it there are thinks
it handles well and that are easier to do than in VB or other languages. I
still can't really say that for C# vs VB.Net
> All C# has to do is keep 1.5 million developers loyal to the semi-colon
and
> it won't get rolled over by VB.NET ;)
But VB.Net has to keep several million loyal to the "End xxxx" syntax to
prevent that steamroller from going the other way <g>
Rockford Lhotka
and
> > it won't get rolled over by VB.NET ;)
>
> What do millions of VB developers have to do to keep from getting rolled
> over by B#? Loyalty alone doesn't seem to be enough!
Because at least some large number of us _asked_ for most of the changes
we're getting, and are perfectly happy to roll with those that we didn't ask
for in order to get what we do want.
The company I work with, Magenic Technologies, has several clients that are
building apps or doing pilots using .NET - using both VB.NET and C#. No one
using the new stuff has any interest in going back - that's true of our
consultants and of the developers from the clients.
Face it - most people, after working with .NET for just a couple weeks, WANT
to get rolled over ;)
JP Hamilton
VB.NET are not using it. I love it! I am coding in it several hours a day
now. The thought of using VB6 makes me cringe. Sorry, but those of you who
have been putting off learning OOP for all these years are in for a shock.
But I bet that most of you will never want to go back once you get an idea
of what can be done.
--JP
P.S. I am in no way affiliated with Microsoft:)
"Rockford Lhotka" <ro...@lhotka.net> wrote in message
news:e0y4mqE9AHA.1032@tkmsftngp07...
Joe "Nuke Me Xemu" Foster
> Joe,
> Thats not entirely true, Class Assist simulated inheritance. But it wasn't
> truly inheritance.
Hey, the first C++ "compilers" were merely a front-end to a K&R C compiler
and a fixup utility which ran after the linker, yet it worked well enough.
If you insisted on being offended by mere "simulated inheritance", it was
easy enough to intercept the generated C code and sniff dismissively.
--
Joe Foster <mailto:jfo...@ricochet.net> Space Cooties! <http://www.xenu.net/>
Joe "Nuke Me Xemu" Foster
> Yes! Thank you! I have to say that I think most of the people who don't like
> VB.NET are not using it. I love it! I am coding in it several hours a day
> now. The thought of using VB6 makes me cringe. Sorry, but those of you who
> have been putting off learning OOP for all these years are in for a shock.
> But I bet that most of you will never want to go back once you get an idea
> of what can be done.
Is it possible to have reasons to object to B# other than "fear of new
technology"? Could someone already familiar with OOP through such crusty
old OOP languages as C++, Eiffel, Smalltalk, VB4/5+ClassAssist, etc.,
have no possible reservations about this new language masquerading as VB?
> P.S. I am in no way affiliated with Microsoft:)
Are you sure about that? They have been known to fund "think tanks" to
spew about how Microsoft should have the freedom to innovate new ways to
cut off their competition's air supply...
JP Hamilton
sinker. There are definately things that are objectionable. I definately
think people should state specifically what bothers them. The "VB sucks"
posts get old after awhile . Like the guy who posted recently "VB < C#".
What a troll!
Now, let's talk specifics. Is there really a VB language? If so, where's the
spec? Is it defined by VB 6. Or should I read the documentation for versions
1-5, too? Wouldn't it be cool if MS formalized the language? I think so.
Then we can hear an end to all this bitching.
Think about C for a minute. Is printf a part of the C Language? No, its not.
So are Left, Mid, and Right apart of the VB language? Or are they functions
that people are used to having around? Personally, I think Mid sucks. I'll
never use it again. To me, its just a function. It's not VB.
Its not like Microsoft changed Dim or For...Next or Do...While or If...Then.
These are the elements of the language. This is VB.
My beefs? Well, why the new Shared keyword when Static was already apart of
the language? How come array declaration syntax always has to be catered
towards people who are too stupid to use an array in the first place? What
good programmer cares what True evaluates to? How come when we finally get a
chance to get a good, cleaned up version of VB, invariably we are stuck with
yet another compromised version?
Anyway, as far as languages go.....haven't you guys figured out that a
language in .NET is pretty much like a Winamp skin?
Let the flames begin!!!!!!!!!!!!!!!!!
--JP
P.S. Speaking of Eiffel, I think I am going to learn that next.
"Joe "Nuke Me Xemu" Foster" <j...@bftsi0.UUCP> wrote in message
news:OgsFOIK9AHA.1900@tkmsftngp04...
Gregor R. Peisker
> > Joe,
> > Thats not entirely true, Class Assist simulated inheritance. But it wasn't
> > truly inheritance.
>
> Hey, the first C++ "compilers" were merely a front-end to a K&R C compiler
> and a fixup utility which ran after the linker, yet it worked well enough.
> If you insisted on being offended by mere "simulated inheritance", it was
> easy enough to intercept the generated C code and sniff dismissively.
But isn't there a difference between a compiler trick that hides the "this"
argument, and the smoke & mirrors that Class Assist put up? I remember the last
(and only) time I used it, it just duplicated all the ugly code it produced for
the "derived" class. Likewise, if you use delegation, you end up creating twice
as many instances.
Regards,
Gregor
Joe "Nuke Me Xemu" Foster
And just what do you think happens "under the covers" in languages with
"true inheritance"? True, you might have hybrids, such as copies of the
ancestors' data members while their methods are delegated, but Sheridan
made the choices they did to have decent performance. Even if all the
inherited members were copied willy-nilly into sagans of descendants,
they only needed to be maintained by hand in *one* place.
--
Joe Foster <mailto:jfo...@ricochet.net> Auditine Addict <http://www.xenu.net/>
Michael Venuto
"MS NET" <Dave_B...@grsinc.com> wrote in message
news:OhYPhSz8AHA.2040@tkmsftngp03...
> > It's pretty obvious that VB.Net and C# are redundant. The sad fact is
> that MS
> > has lost sight of what VB is all about.
>
> I believe the sad fact is someone doesn't seem to know a whole lot about
> either language..........
>
>
>
> "Thomas Banks" <tba...@aol.comnospam> wrote in message
> news:20010609131138...@ng-fh1.aol.com...
> > >I'm not saying VB is a fundamentally poor language. I'm saying that MS
> is
> > >maintaining two distinct languages with a very large overlap in target
> > >market and that I expect them to phase 1 out over time and I expect
that
> to
> > >be VB.Net. I'm definitely not saying that's a good thing, just that I
> > >expect it to happen.
> >
> > It's pretty obvious that VB.Net and C# are redundant. The sad fact is
> that MS
> > has lost sight of what VB is all about. Given the choice of making
VB.Net
> a
> > natural extension of VB 6 or forcing all languages into the
> one-size-fits-all
> > .Net platform, they chose the latter.
> >
> > There is no purpose for having both VB.Net and C# as languages other
than
> the
> > ability to market the VB name to VB developers and C# to C/C++
developers.
> >
> > It's tiresome to hear people claim that VB 6 had to be thrown out to
> become a
> > modern language. Features like threads and even OO don't force the
> language to
> > be incompatible with previous versions nor do they require the radical
> changes
> > to syntax that MS has made. These changes were made necessary only by
> MS's
> > insistence that VB fit like a glove in the .Net framework which is their
> latest
> > idea to extend their WinTel monopoly while fighting off pretenders to
the
> > throne like Linux/Unix, Delphi and Java.
> >
> > So, VB.Net superficially retains some of its syntax while stealing every
> idea
> > from Java MS can stuff into it. We get lip service to cross platform
> > compatiblity in the future which is just so much smoke in the air.
> >
> > And MS will get away with it because they are so dominant in the
industry.
> >
> >
>
>
Patrick Steele
no_spam!mi...@grsinc.com>),
> This from a guy who thought ASP.NET was written in J++???
This from a guy who believed him??? :)
--
Patrick Steele
(pst...@ipdsolution.com)
Lead Software Architect
Image Process Design
Michael Venuto
What in the hell are you talking about? Please direct all replies to
somepeopl...@yourdesk.com
Michael J. Venuto
"Patrick Steele" <pst...@ipdsolution.com_> wrote in message
news:MPG.1592d4f48...@msnews.microsoft.com...
Patrick Steele
no_spam!mi...@grsinc.com>),
> What in the hell are you talking about?
Check the thread "what is the best in .net? c# or vb?", your post on
6/07 (approx. 12:10PM). You said:
"However, you're mistaken about ASP.NET - it was definitely written in
J++. Some weeble here it the office said he heard it from a guy who
heard it from a guy who knows someone at Microsoft."
:O