Microsoft's C++ bigotry

[Mike Mitchell]

On Fri, 24 Jan 2003 10:01:09 -0000, "Gary Nelson" <gn@contanet.es>
wrote:

>I think that's what we are all saying. How can I get up to speed in .net if
>I have to spend most of the time in VB6?

Well, the short answer is, I think, you can't! It's a choice. And that
is the problem. This morning I received the Feb 2003 issue of Visual
Systems Journal (www.vsj.co.uk) in which the editorial includes:

<quote>
"Windows programmers are being asked to change their model of the
universe, and they are being sold this idea as something to do with
XML and Web Services. This is verging on the laugable."
</quote>

There is only a certain amount of time in the day and all the while
programmers have to do a particular job just to keep their heads above
water, they're not going to be able to allocate time to learning
something quite different. Even evening classes are done well away
from work, after one has gone home for a couple of hours (at least),
had a chance to relax a bit and take the dog for a walk. One needs to
spend 100% of one's mental resources when learning something new and
if the commitment (let alone a valid reason) isn't there, then failure
or confusion is almost inevitable. That is yet another reason why the
decision to replace VB with VB.Net was daft, as it just doesn't allow
a seamless, gradual changeover. It's all or nothing from the moment
you make the decision to switch.

MM

[Mike Mitchell]

On Fri, 24 Jan 2003 09:59:28 +1100, Jason Sobell iGadget
<igadget_@hotmail.com> wrote:

>A new phrase "the .Netizenry"? Defined as "All who do not despise VB.NET"?

Like the citizenry, but owned by MS....!

MM

[Mark Hurd]

Mike Mitchell wrote:
> On Thu, 23 Jan 2003 13:23:53 +1030, "Mark Hurd"
> <markhurd@ozemail.com.au> wrote:
>
> > It *is* a good excuse to rewrite your code, if you can afford it. And,
> > yes, I expect you'll use less code to produce the same or better result,
> > but then I'd expect any competent programmer to solve the problem better
> > the second time around, even if they used VB6 again.
>
<SNIP valid description of a common scenario that corresponds to why a company
cannot afford to rewrite.>

I said the above because many people defending (selling) .NET say that they're
pleased with the result of upgrading to .NET because they've got a better
program with less code. I believe the .NET Framework is a reason for that, but
so is the fact that you're rewriting the program -- re-solving the problem.

Regards,
Mark Hurd, B.Sc.(Ma.) (Hons.)

[Larry Serflaten]

"Gary Nelson" <gn@contanet.es> wrote
> > Adding a class...
>
> Classes are very useful, but are very different from Gosub
>
> Using a class for something like that is overkill, plus it converts a very
> simple structure (Gosub) into something much more comples (a class)


Then use a standard module. You are using Gosub because it is
convenient, not because it is needed. VB has a lot of 'convenient'
features that should not show up in a well written program....

LFS

[Paul Clement]

On Thu, 23 Jan 2003 20:38:29 -0000, "Jonathan West" <jwest@mvps.org> wrote:

¤
¤ "Dave" <dave_doknjas@yahoo.ca> wrote in message
¤ news:3e304d64$1@tnews.web.devx.com...
¤
¤ > Well... the "first make it work, then make it work well" principle is
¤ usually
¤ > applied to code in early development, prior to official release, but I
¤ guess
¤ > that's not Microsoft's approach.
¤
¤ Historically, it's usually been v3 of a product before Microsoft has been
¤ able to make it work right.
¤
¤ What I do find interesting though is how Paul shuffles between "its only
¤ version 1 of a new product, you can't expect much of it" and "its not a new
¤ language, its an upgrade to an existing one" according to the nature of the
¤ point he's wanting to answer.

No shuffling. It's the first version of the next generation of the product just as Visual Basic was
to BASIC. AFAIK Microsoft named it Visual Basic .NET not Visual Basic 7.0, although it probably
doesn't matter. It's still an upgrade just as Visual Basic 1.0 was.

¤
¤ Paul, it's either new or it's not, but unless Microsoft has made a
¤ breakthrough in quantum computing, it can't both be new and not-new at the
¤ same time!

Sure if everything was black or white and there was no in between. It can certainly be a new
generation of the product without calling it a new language. There's a lot of new, but much of the
old still remains.


Paul ~~~ pclement@ameritech.net
Microsoft MVP (Visual Basic)

[Paul Clement]

On Thu, 23 Jan 2003 21:59:10 -0000, "Jonathan West" <jwest@mvps.org> wrote:

¤
¤ "Phil Weber" <pweber@nospam.fawcette.com> wrote in message
¤ news:3e305215$1@tnews.web.devx.com...
¤ > > Paul, it's either new or it's not...
¤ >
¤ > Jonathan: I'm Phil. Do you have me confused with Paul?
¤
¤ In that particular case, yes. However, I'll stand by the statement regarding
¤ Paul in general terms, given that the following has appeared from him within
¤ this thread.
¤
¤ We have these:
¤
¤ "When you consider the number of actual changes to the core language (which
¤ many of the VB.NOT folks enjoy clamoring about) they amount to a very small
¤ and almost insignificant part of the language."
¤
¤ "Well first the changes to the actual language were few as I indicated."
¤
¤ "VB.NET isn't a new language."
¤
¤
¤ And we have these:
¤
¤ ""Classic" VB is/was a dead end. Microsoft was unable to evolve it beyond
¤ what it was. It's a great tool for building Windows desktop apps or COM
¤ components but that's as far as they were able to go with it. It need to be
¤ re-architected."
¤
¤ "You weren't around when VB 1.0 was released were you? It wasn't until
¤ version 3.0 that it actually started to become popular.
¤ I don't think it's realistic to expect everyone to jump on the .NET
¤ bandwagon right away. It simply isn't practical."


Nothing that I would consider incongruous. Are you reading something into this that isn't written?


Paul ~~~ pclement@ameritech.net
Microsoft MVP (Visual Basic)

[Jonathan West]

"Larry Serflaten" <serflaten@usinternet.com> wrote in message
news:3e314b69@tnews.web.devx.com...
> "Gary Nelson" <gn@contanet.es> wrote
> > > Adding a class...
> >
> > Classes are very useful, but are very different from Gosub
> >
> > Using a class for something like that is overkill, plus it converts a
very
> > simple structure (Gosub) into something much more comples (a class)
>
>
> Then use a standard module. You are using Gosub because it is
> convenient, not because it is needed. VB has a lot of 'convenient'
> features that should not show up in a well written program....

Why are you against convenience? It sounds to me as if you think that there
is One Right Way of writing code, and all alternatives are wrong. Having
seen code from very many people, ranging from the outstanding to the
execrable, I have to say that it just isn't true.

Therefore I am extremely skeptical of people who say you "should not" write
code a specific way unless there is a tangible reason for it. That reason
might be in terms of performance, compiled code size or maintainability, but
there has to *be* a reason.

--
Regards
Jonathan West

[Larry Serflaten]

"Mike Mitchell" <kylix_is@yahoo.co.uk> wrote

> >It is that 'hurry up' attitude that puts buggy code into the hands of the users.
>
> You just cannot say it's wrong, period!

Yes I can.

What other industry can tell you, 'You have only purchased a license to
use the product, you do not own it, and we are not responsible for any
damages you might suffer from using the product' ?

Hiding buggy code behind such agreements is absurd. The usual arguement
is that there is millions of lines of code involved and it is impossible to keep
all the bugs out. But in the end, who's fault is that?

Even when the code/application is free, that is not a license to ship low
quality work. The constant parade of patches we are submitted to is a
direct result of unsufficient quality control and testing on the part of the
vendor.

The situation will not fix itself. Many more vendors and developers have
to adopt this same opinion before we can apply any amount of trust to
computing. Consider the amount of trust you have in picking up your
telephone and getting a dial tone. If you pay your bill, you might not even
check for the tone before dialing the number you plan to call. How much
trust do you have in your refrigerator, keeping your food cold? You leave
it run all day, or may take off for a few days, and still expect your food
to be cold on your return. There are many such comparisions that could
be made, but suffice it to say that computing is still a far cry from such
ubiquity.

I say thats wrong, if you say it isn't then chances are you'll do nothing to
make it better. That is also a part of the problem....

LFS

[Paul Clement]

On Thu, 23 Jan 2003 14:18:29 -0600, Dan Barclay <Dan@MVPs.org> wrote:


¤
¤ >It can't hold data specific to its function and it isn't a parent to its code. It's a code
¤ >navigational structure.
¤
¤ The same would be true for masm Call/Ret as well, eh?

No. A Sub or Function doesn't affect the flow of code (navigation) in the calling routine - it
simply suspends execution until control is returned. A GoSub/Return does control the flow of
execution - it is part of the functioning code in the Sub or Function which contains it. That is the
problem.

¤
¤ >¤
¤ >¤ >It causes the code to branch down and then back up through the code in its container - a prime
¤ >¤ >example of spaghetti code.
¤ >¤
¤ >¤ LOL. You've *got* to be kidding. This is exactly what Subs and
¤ >¤ Functions do, by your definition, except that they also carry their
¤ >¤ own variable space. We've gotta stop that Sub branching, yessireee.
¤ >
¤ >Nope. They do not inherently branch down, bypassing a chunk of code, and then return when they're
¤ >finished.
¤
¤ Really? Every sub/function and GoSub I've seen does exactly this.

A Sub, Function or method call to an instanced Class does not do this. If you have a snippet code
that demonstrates your claim you are welcome to post it.

¤
¤ >I can't imagine that you need to be drawn a road map documenting the flow of logic between a GoSub
¤ >and Subs or Functions. You've been doing this stuff long enough to know that.
¤
¤ You're right. I've done it once before, and I understand it fairly
¤ well. Heck, I even wrote a class once.

Well then I guess you understand the distinction after all.

¤
¤ >
¤ >¤
¤ >¤ Hmmm... have you been implementing your GoSubs using GoTo's and
¤ >¤ branches? Like I said, maybe you should learn something about it.
¤ >
¤ >Perhaps you should learn about Subs and Functions so you can discriminate between them and GoSub.
¤ >Are you finished now?
¤ >
¤ >¤
¤ >¤ Sounds like all you want in your toolbox is a hammer. Why do you
¤ >¤ insist that everybody else leave their screwdrivers at home as well?
¤ >
¤ >How about using the more efficient tool? Accepting the fact that GoSub was significantly slower
¤ >(regardless of what MS intended it to be), why still use it? Or do you use a screwdriver to pound in
¤ >nails?
¤
¤ If it were fixed (it can be) and were faster than Sub/Function, would
¤ you argue that I should be using GoSub instead of Sub/Function??

Nope, because of the inherent problem of creating spaghetti code. And if the GoSub implementations
you are referring to are as straightforward as you say they are I see no reason why they can't be
converted to an actual container such as a Sub or Function. If the GoSub implementations are not as
straightforward, then you will likely have a maintenance problem when someone else has to review
your code.

¤
¤ Performance is the decision point only on "hot" code that has high
¤ impact on your overall app's performance. In the remaining 99.9% of
¤ code, maintenance and readability are more appropriate decision
¤ points.

It's much cheaper to buy the performance that you may sacrifice in order to write more readable
code, than to pay someone to maintain, convert, or fix code that is difficult to decipher.

¤
¤ >¤ >¤ In most places I use them it would require extensive parameter lists.
¤ >¤ >¤ The idea is to eliminate duplicated code fragments for maintenance
¤ >¤ >¤ reasons, but to replace them with equally long parameter lists or,
¤ >¤ >¤ (God forbid) module level variables would only trade one problem for
¤ >¤ >¤ another.
¤ >¤ >
¤ >¤ >Well I think you know from our past discussions that I will never buy this. First GoSub is a
¤ >¤ >branching mechanism.
¤ >¤
¤ >¤ Branching mechanism? That's why it was initially implemented with
¤ >¤ Call/Ret, huh?
¤ >
¤ >Does it matter?
¤
¤ Only if you think it's a branching mechanism. GoSub does not create a
¤ logical branch. It executes code as if it were inline, returning to
¤ the next statement.

Well no I don't consider a call to a Sub or Function a branching mechanism. Branching occurs within
a code container.

¤
¤ >
¤ >¤
¤ >¤ >Branch and returns (used instead of Subs and Functions) lead to some rather
¤ >¤ >confusing and difficult to debug code. It also unnecessarily increases the size of Subs and
¤ >¤ >Functions, causing the same types of problems.
¤ >¤
¤ >¤ Nope.
¤ >¤
¤ >¤ Please see my previous discussion (which you snipped) regarding taking
¤ >¤ the effort to properly use it.
¤ >
¤ >Doesn't matter. As I said before it directly affects the flow of logic in your Sub or Function. The
¤ >execution of code in the Sub or Function flows in both directions which makes code more difficult to
¤ >work with.
¤
¤ Nope, it does not affect the logic.

I said it affects the "flow" of logic.

¤
¤ >¤ Oh, and while you're at it maybe you should educate some of the idiots
¤ >¤ on how to use classes before someone gets the bright idea that we
¤ >¤ should be protected from those as well.
¤ >
¤ >Except they aren't inherently poor structures.
¤
¤ That's what you and I think. There are some folks who don't agree
¤ with us. I've found, from experience, that those folks sometimes get
¤ the ear of the implementors.

Well they're wrong. ;-)

¤
¤ >¤ Holy cow! Just think of the crap someone is going to write using
¤ >¤ inheritance!!! ****, I was planning to use that some day and now
¤ >¤ they'll probably remove it because it has sharp edges.
¤ >¤
¤ >¤ >If you are worried about long parameter lists, you can use a parameter array.
¤ >¤
¤ >¤ Same issue. It adds complexity where none is needed. Keep it
¤ >¤ simple...
¤ >
¤ >You use GoSub and you're complaining about complexity? ;-)
¤
¤ GoSub is a far more simple construct than even Sub/Function, much less
¤ classes or inheritance. Do not confuse power with simplicity. In
¤ fact, the more powerful features are generally the more complex.

I guess we're going to have to just disagree on this point. The concept of GoSub is simple, the
implementation causes code maintenance headaches.


Paul ~~~ pclement@ameritech.net
Microsoft MVP (Visual Basic)

[Paul Clement]

On Fri, 24 Jan 2003 10:42:54 -0000, "Gary Nelson" <gn@contanet.es> wrote:

¤ Paul,
¤
¤ > Which is why it isn't a container since entry can be accomplished via a
¤ branch call or via the
¤ > sequential execution of code. That is, unless you either skip over the
¤ GoSub code programmatically
¤ > or Exit the Function or Sub prior to its execution.
¤
¤ ????
¤
¤ All of my Gosubs are below an Exit Sub or Function.
¤
¤ How could you do it any other way?

OK, I'm confused. How do you execute a GoSub statement if it's after an Exit Sub or Function. Or do
you mean that you have a bunch of code in between the GoSub call and the label above the code that
is to be executed when it is called? So in that case the flow of execution in the Sub or Function
branches down to execute that code and then returns back up to the line after the GoSub call to
execute the code in between the GoSub call and the GoSub code at the bottom of the Sub or Function.

¤
¤ If you do a sequential entry into a Gosub routine you will get a Return
¤ without Gosub error when it hits the Return.

Right on that one. Guess it's been a while since I used it. ;-)

Still not a code container though.


Paul ~~~ pclement@ameritech.net
Microsoft MVP (Visual Basic)

[Paul Clement]

On Thu, 23 Jan 2003 21:05:18 +0000, Mike Mitchell <kylix_is@yahoo.co.uk> wrote:

¤ On Thu, 23 Jan 2003 12:02:40 -0800, "Phil Weber"
¤ <pweber@nospam.fawcette.com> wrote:
¤
¤ > > But I'm curious, perhaps you have a machine that computes
¤ > > differently than most...[run] the code below, and report your
¤ > > findings, just to check if it matches what the rest of us see...
¤ >
¤ >Larry:
¤ >
¤ > Gosub took: 1282
¤ > Subroutine took: 4436
¤
¤ Thank God! Now, for f***'s sake, let's fuggedabout GoSub for

>>five ruddy minutes!<

You misspelled "forever". ;-)


Paul ~~~ pclement@ameritech.net
Microsoft MVP (Visual Basic)

[Paul Clement]

On 23 Jan 2003 11:22:16 -0800, "Kent" <kp@kp.org> wrote:

¤
¤ If that is the migration path, then no one should be surprised that some existing
¤ shops and customers refuse to use VB.Net.
¤

And that's why those of us who support .NET believe that much of the complaining about
incompatibility is simply a red herring and that the dislike for it extends beyond this issue.


Paul ~~~ pclement@ameritech.net
Microsoft MVP (Visual Basic)

[Paul Clement]

On Fri, 24 Jan 2003 11:07:23 -0000, "Gary Nelson" <gn@contanet.es> wrote:


¤ > The bottom line is that you have a migration path. If the performance of
¤ Mid is unacceptable you can
¤ > change it (now or later), but for the time being you have functioning code
¤ in a VB.NET app. That may
¤ > not be exactly what you want but its preferable over the functionality
¤ being dropped altogether.
¤
¤ The problem is that the performance of my program must at least be
¤ comparable to the VB6 version when I make the transition in order to please
¤ my clients. I can't throw a second class program on them and then tell them
¤ to wait till I get it up to par.

That's not an uncommon issue when upgrading to a new version of Visual Basic. It happened when
ActiveX components were introduced to Visual Basic as a replacement for VBXs and Visual Basic became
COM based.

Retaining Mid may not be your solution then and in order for the app to be on par performance-wise
you will need to convert to the newer functions. Or, you stick with Visual Basic 6.0 for the time
being.


Paul ~~~ pclement@ameritech.net
Microsoft MVP (Visual Basic)

[Larry Serflaten]

"Jonathan West" <jwest@mvps.org> wrote

> Why are you against convenience?

More times than not, it is not needed, and there are better ways to get the
job done. In the case of Gosub, a separate procedure is often a better
route. In the case of Variants, strongly typed variables are often a better
route. There are other such examples...

> It sounds to me as if you think that there
> is One Right Way of writing code

That's your perception, I never said that....


> Therefore I am extremely skeptical of people who say you "should not" write
> code a specific way unless there is a tangible reason for it. That reason
> might be in terms of performance, compiled code size or maintainability, but
> there has to *be* a reason.

Take your pick, it is sometimes less performant, and sometimes difficult to
maintain, depending on how badly it has been abused. You know there is a
religious admonition agaist using End to stop a program, yet some still have
to be told not to use End. MS has been hinting Gosub is on its way out
since about version 4, yet some people still use it....

<quote>
Tip Creating separate procedures that you can call may provide a more structured alternative to using GoSub...Return
</quote>

How many other help topics do you see where they specifically mention using
an alternative? (Not many!)

LFS

Mike Mitchell <kylix_is@yahoo.co.uk> wrote:
>On 23 Jan 2003 11:55:26 -0800, "Bob" <vb.@127.0.0.1> wrote:
>
>>So if Mike isn't lying or crazy according to his own statement, he isnt'
>>developing in VB anymore--any version. Which is it Mike? Are you crazy
or
>>just spreading FUD?
>
>I'm neither crazy, nor spreading FUD. All I asked was, did anyone test
>out the claims that GoSub is slower than achieving the same
>functionality through calling a Sub multiple times and passing maybe a
>dozen arguments?
>
Why don't you test it and find out? That's what real programmers do, Mike.