.NET equals Efficiency

[Kathleen \(MS MVP\)]

Bill,

Good to see you drop round.

Thanks very much for some hard numbers!

Kathleen

[Patrick Meader]

>> Yeah, especially after the .notters blamed him for single-handedly
causing the demise of VB6.

I think he was simply quoted as taking credit for that. If you feel
otherwise, can
you provide a cite?<<

That's BS, Karl.

[Paraphrasing, of course] He was quoted as saying that backward
compatability has longterm costs that are often missed or ignored, and that
it's cheaper in the long run to break compatibility in *some* cases. He felt
this was such a case. He was also quite explicit in saying that he was one
of several people at a particular meeting, and that the team responsible for
developing the VS.NET project considered many other POVs--not just the
opinions of those gathered.

Extrapolating that to him being the cause of VB6's alleged demise is just
hyperbole. Fun, maybe, but not very nice.

I'd post that cite you ask for, but well, I can't seem to find it [blushes].
From the number of times you've quoted a particular line from that
interview, I'd have wagered a decent sum that you know where to find it
<gd&r>.

pat

[Phil Weber]

> I'd post that cite you ask for, but well, I can't seem to find
> it [blushes].

Pat: When are you going to learn how to use our search engine? ;-) A search
for "(bill or william) w/2 storage and backward compatibility" found it in
about two seconds:
http://www.fawcette.com/archives/pre...aug01/dk0108/s
ide5.asp
---
Phil Weber

[Patrick Meader]

Hi Phil:

>>When are you going to learn how to use our search engine? ;-)<<

Well, I think of it as the history article!

Typing in "history bill storage" and "history" returned nothing relevant for
me.

>>found it in about two seconds<<

Show off. But thanks!

[W.E.(Bill) Goodrich, PhD]

In article <3c734271@10.1.10.29>,
"Bill Storage" <storage@bplusmylastname.com> writes:

> Hi Bill-

Hi Bill <-;

> "W.E.(Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote in message
> news:3C732ADB.255B69B@netzero.net...

> > Does that include the "productivity" of the process of migrating
> > them from their B2 CLR to the new CLR?

> Well, the web app committed to running on B2 until its first rev, so
> migration wasn't an issue there.

> The 2 Winform apps migrated (B2-final) with no modification to the
> code. We didn't deploy them until after we had the final build, so
> it wasn't an issue there. Regardless, what is your point? My example
> dealt with productivity differences due to .NET features. How would
> migration pains from B2 to final be relevant to that issue?

Because they generally "consume" the same resources (programmer hours,
etc.) that the original development used, but often are not counted in
the "productivity" claims of certain "early adopter" advocates. But
the issue of such migration costs - current and anticipated - is
significant when evaluating possible use of the toolset.

> > > I'm seeing a factor of 2 to 3 improvement in coding time over
> > > VB6 and ASP.

> > OTOH, I recently described a company I know that produced 200+
> > shrink-wrap products over that same year using VB6 (and VC6).
> > Three doesn't look like all that much.

> Are you saying that my sample is too small, or that your pals write
> more code than mine?

No, I was indicating that your statement contained too little
contextual information to be meaningful in this discussion. You gave
no real indication of the nature or features of your apps. While
there are posters to this group who are so desperate to support their
position that they claim that VS.NET is better for *everything* than
VS6, the more responsible advocates acknowledge that such is not the
case.

Not even your name provides such context, given the prevalence of
posting pseudonyms and coincidental names (there are hundreds of Bill
Goodrichs in the "English speaking world" these days).

> We wrote a lot of VB6 code too - hundreds of thousands of lines of it
> in one app alone last year, and have over a million users of another
> app.

Does that mean there are more than a million copies on users' machines,
or that the app resides on some sort of server/s and is accessed by
more than a million users? The distinction makes quite a difference.

> Our VB7

VB7 was killed in favor of VB.NET. The use of "VB7" as another name for
VB.NET v1 only confuses the issue unnecessarily.

> apps were similar to our VB6 apps, so I was comparing very similar
> projects built by the same people with two different dev products.

But without indicating the nature of those projects, the comparison is
not all that meaningful.

> > Do you think that it might have something to with the nature of
> > your app rather than the number? That *some* apps may be more
> > productive in VS6 than in .NET?

> Undoubtedly it does, and undoubtedly there are. Very small apps are
> likely to be easier to build in VB6 than .NET. For example, VB7

see above

> requires that the coder understand the difference between a designer,
> a class, and an instance of the class for any app having more than
> one form. You still get the single-form auto-instantiation for free,
> but those who depended on it will have trouble when they attempt to
> display an instance of Form2 by calling Form2.Show.

One of the many facts which interfere with reuse of legacy code (a
significant factor in productivity for many shops).

> I don't think I've ever sold an Windows app that didn't really
> require understanding objects and instances.

Which gets us right back to the nature of your apps, and the relevance
of that nature to the claim ".NET equals Efficiency" under discussion.
While I haven't looked at *all* of the products produced by the group
I mentioned, I seriously doubt that *any* of them require
understanding objects and instances.

> I'm absolutely sure I've never worked on a web project that didn't
> require that knowledge.

While that is fine for "web projects", there are far more kinds of
applications than that. While even the most vociferous .NET critics
concede its utility for large-scale web projects, there is much more
serious disagreement over its utility for small- and medium-scale
single system (and simple client/server) applications (including
shrink-wrapped consumer products).

> I suspect that the majority of MS's dev product income is derived
> from companies with projects more like mine than like Hello World.

Interesting false dichotomy. And yes (especially given recent changes
in licensing policy) they probably do derive more short term, direct
"dev product" income from companies writing gigantic internal-use
business applications than from those writing games and other consumer
applications. And I would hardly categorize programs like Tomb Raider,
PowerDVD, Music Studio 2000, or even TurboTax as "Hello World" apps.
But the parent corporation stands to lose far more income - and (far
more importantly in terms of corporate values, market control) - if
they are seen as abandoning the consumer market or slow down the flow
of third party consumer products.

> BTW, our least experienced folks had very little difficulty grasping
> OOP principles and gaining productivity/reducing line count by their
> use.

Again, likely an application-specific result. And then there is the
issue of the costs of such retraining.

> By far the biggest hurdle was adjusting to ADO.NET, which is obviously
> independent of the VB language.

And which rarely - if ever - affects consumer applications.

> Oddly, people who never used ADO (old) often had less trouble than
> ADO veterans.

Not odd at all - less to unlearn.

> Finally, our error rate (we track and categorized errors per line
> of code)

Another metric which is more meaningful for gigabyte business
applications than for home consumer (or even small business) apps.
One error per thousand lines is trivial in a 5,000-10,000 line home
app, but potentially disastrous in a "hundreds of thousands of lines"
business app.

Out of curiosity, does your metric include design and documentation
errors? IOW if the spec is wrong and the programmer codes the spec
as written, does that "count" as an error? Or "tried and discarded"
algorithms?

> was greatly reduced. So, world hunger being out of scope here, we
> really are finding .NET to be quite a big deal.

....For your specific niche. OMMV.

> I'm surprized at all the jaded cynicism around here.

Why? Micro$oft has withdrawn a good general purpose development suite
and replaced it with a much more narrowly special purpose suite. It
has taken a very popular RAD and beginner's general purpose language
and replaced it with a broadly incompatible product with the same name
but a much higher ramp-up and conversion cost and the loss of several
useful capabilities (NC compile, DF, etc.). One which essentially no
longer supports the primary description of the earlier product
(program development for the Windows platforms), and shifts to
development for a new, large (20MB) virtual platform. And oh, yes...
even that will not run on millions of consumer (and to a lesser extent,
business) machines.

And on top of that, we see irresponsible enthusiasts claiming that it
is "better" than the old tools for producing *any and all* kinds of
software - a proposition that is blatantly untrue.

> Be happy. Write some **** code.

We are writing plenty of code - much of it in the areas for which VS.NET
is clearly unsuited. For instance, a program which (on consumer systems
under Win95/98/ME - no XP yet) monitors a group of analog sensors, doing
real-time DSP and displaying/graphing selectable frequency responses.
The project also required that we create the drivers for the sensor
interfaces (obviously not a VB portion of the project). Hardly a "Hello
World" project, but one well suited to VS6 and our non-OOP design style.

Another recent one performs and evaluates certain forms of psychometry,
graphing responses against certain "norms" and reporting various other
relevant results.

Generally speaking, our programs are response-time sensitive and do
not involve internet/intranet communications or large scale databases.
They run to the low tens of thousands of lines (if that) rather than
the hundreds of thousands. They often have to run on old hardware,
under consumer OSs (Win95 and up). They are modular, but not OO. And
they are produced quickly and effectively.

--

W.E. (Bill) Goodrich, PhD

*-----------------------*--------------------------------------------*
* CHANGE YOUR SEXUALITY * http://www.nyx.net/~bgoodric/ctg.html *
* * *
* Without Aversive * ctgcentral@earthlink.net *
* Behavior Modification * Creative Technology Group *
* or Drugs * PO Box 286 *
* * Englewood, CO 80151-0286 *
*-----------------------*--------------------------------------------*

[Karl E. Peterson]

Hi Pat --

> >> Yeah, especially after the .notters blamed him for single-handedly
> causing the demise of VB6.
>
> I think he was simply quoted as taking credit for that. If you feel
> otherwise, can you provide a cite?<<
>
> That's BS, Karl.

What is? That the ".notters" blame Bill for destroying the language? Of course it
is, that's why I asked for a cite.

But the article you reference pretty clearly makes the case that he was all in favor
of busting the **** outta the langauge, and to date he's the only one willing to
stand up and state it without hesitation. That's "taking credit" in the books of
many. Certainly trying to make it appear that his voice had an influence on the
ultimate decision to hose so many customers.

> [Paraphrasing, of course] He was quoted as saying that backward
> compatability has longterm costs that are often missed or ignored, and that
> it's cheaper in the long run to break compatibility in *some* cases.

Too bad he didn't do the responsible thing, and advocate for a new language that more
closely met his needs, rather than trying to represent the costs for millions of
others.

> Extrapolating that to him being the cause of VB6's alleged demise is just
> hyperbole. Fun, maybe, but not very nice.

As I said, I'd like a citation for that extrapolation. So far, it's only
cheerleaders that even suggest such a charge has been leveled. If you're arguing
with them, well, by all means carry on.

Later... Karl
--
[Microsoft Basic: 1976-2001, RIP]

[Patrick Meader]

Hi Karl:

Misunderstood your original post. I thought you were saying that Bill took
credit for the "demise" of the language. That wasn't your point, so my
apologies.

[Bill Storage]

This is more detail than I intended to get into, so I'll drop back to a
summary. We concluded .NET gave us substantial productivity improvements.

I have a VB6 app running on the desktops of about a million users. We will
probably never rewrite it in VB7. I intend to maintain the VB6 code for at
least three years.

Spelling Microsoft will dollars signs (Micro$oft) IMO makes you look like an
***. Companies exist to make money.

Bill



"W.E.(Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote in message
news:3C744386.F43DE3BE@netzero.net...
> In article <3c734271@10.1.10.29>,
> "Bill Storage" <storage@bplusmylastname.com> writes:
>
> > Hi Bill-
>
> Hi Bill <-;
>
> > "W.E.(Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote in message
> > news:3C732ADB.255B69B@netzero.net...
>
> > > Does that include the "productivity" of the process of migrating
> > > them from their B2 CLR to the new CLR?
>
> > Well, the web app committed to running on B2 until its first rev, so
> > migration wasn't an issue there.
>
> > The 2 Winform apps migrated (B2-final) with no modification to the
> > code. We didn't deploy them until after we had the final build, so
> > it wasn't an issue there. Regardless, what is your point? My example
> > dealt with productivity differences due to .NET features. How would
> > migration pains from B2 to final be relevant to that issue?
>
> Because they generally "consume" the same resources (programmer hours,
> etc.) that the original development used, but often are not counted in
> the "productivity" claims of certain "early adopter" advocates. But
> the issue of such migration costs - current and anticipated - is
> significant when evaluating possible use of the toolset.
>
> > > > I'm seeing a factor of 2 to 3 improvement in coding time over
> > > > VB6 and ASP.
>
> > > OTOH, I recently described a company I know that produced 200+
> > > shrink-wrap products over that same year using VB6 (and VC6).
> > > Three doesn't look like all that much.
>
> > Are you saying that my sample is too small, or that your pals write
> > more code than mine?
>
> No, I was indicating that your statement contained too little
> contextual information to be meaningful in this discussion. You gave
> no real indication of the nature or features of your apps. While
> there are posters to this group who are so desperate to support their
> position that they claim that VS.NET is better for *everything* than
> VS6, the more responsible advocates acknowledge that such is not the
> case.
>
> Not even your name provides such context, given the prevalence of
> posting pseudonyms and coincidental names (there are hundreds of Bill
> Goodrichs in the "English speaking world" these days).
>
> > We wrote a lot of VB6 code too - hundreds of thousands of lines of it
> > in one app alone last year, and have over a million users of another
> > app.
>
> Does that mean there are more than a million copies on users' machines,
> or that the app resides on some sort of server/s and is accessed by
> more than a million users? The distinction makes quite a difference.
>
> > Our VB7
>
> VB7 was killed in favor of VB.NET. The use of "VB7" as another name for
> VB.NET v1 only confuses the issue unnecessarily.
>
> > apps were similar to our VB6 apps, so I was comparing very similar
> > projects built by the same people with two different dev products.
>
> But without indicating the nature of those projects, the comparison is
> not all that meaningful.
>
> > > Do you think that it might have something to with the nature of
> > > your app rather than the number? That *some* apps may be more
> > > productive in VS6 than in .NET?
>
> > Undoubtedly it does, and undoubtedly there are. Very small apps are
> > likely to be easier to build in VB6 than .NET. For example, VB7
>
> see above
>
> > requires that the coder understand the difference between a designer,
> > a class, and an instance of the class for any app having more than
> > one form. You still get the single-form auto-instantiation for free,
> > but those who depended on it will have trouble when they attempt to
> > display an instance of Form2 by calling Form2.Show.
>
> One of the many facts which interfere with reuse of legacy code (a
> significant factor in productivity for many shops).
>
> > I don't think I've ever sold an Windows app that didn't really
> > require understanding objects and instances.
>
> Which gets us right back to the nature of your apps, and the relevance
> of that nature to the claim ".NET equals Efficiency" under discussion.
> While I haven't looked at *all* of the products produced by the group
> I mentioned, I seriously doubt that *any* of them require
> understanding objects and instances.
>
> > I'm absolutely sure I've never worked on a web project that didn't
> > require that knowledge.
>
> While that is fine for "web projects", there are far more kinds of
> applications than that. While even the most vociferous .NET critics
> concede its utility for large-scale web projects, there is much more
> serious disagreement over its utility for small- and medium-scale
> single system (and simple client/server) applications (including
> shrink-wrapped consumer products).
>
> > I suspect that the majority of MS's dev product income is derived
> > from companies with projects more like mine than like Hello World.
>
> Interesting false dichotomy. And yes (especially given recent changes
> in licensing policy) they probably do derive more short term, direct
> "dev product" income from companies writing gigantic internal-use
> business applications than from those writing games and other consumer
> applications. And I would hardly categorize programs like Tomb Raider,
> PowerDVD, Music Studio 2000, or even TurboTax as "Hello World" apps.
> But the parent corporation stands to lose far more income - and (far
> more importantly in terms of corporate values, market control) - if
> they are seen as abandoning the consumer market or slow down the flow
> of third party consumer products.
>
> > BTW, our least experienced folks had very little difficulty grasping
> > OOP principles and gaining productivity/reducing line count by their
> > use.
>
> Again, likely an application-specific result. And then there is the
> issue of the costs of such retraining.
>
> > By far the biggest hurdle was adjusting to ADO.NET, which is obviously
> > independent of the VB language.
>
> And which rarely - if ever - affects consumer applications.
>
> > Oddly, people who never used ADO (old) often had less trouble than
> > ADO veterans.
>
> Not odd at all - less to unlearn.
>
> > Finally, our error rate (we track and categorized errors per line
> > of code)
>
> Another metric which is more meaningful for gigabyte business
> applications than for home consumer (or even small business) apps.
> One error per thousand lines is trivial in a 5,000-10,000 line home
> app, but potentially disastrous in a "hundreds of thousands of lines"
> business app.
>
> Out of curiosity, does your metric include design and documentation
> errors? IOW if the spec is wrong and the programmer codes the spec
> as written, does that "count" as an error? Or "tried and discarded"
> algorithms?
>
> > was greatly reduced. So, world hunger being out of scope here, we
> > really are finding .NET to be quite a big deal.
>
> ...For your specific niche. OMMV.
>
> > I'm surprized at all the jaded cynicism around here.
>
> Why? Micro$oft has withdrawn a good general purpose development suite
> and replaced it with a much more narrowly special purpose suite. It
> has taken a very popular RAD and beginner's general purpose language
> and replaced it with a broadly incompatible product with the same name
> but a much higher ramp-up and conversion cost and the loss of several
> useful capabilities (NC compile, DF, etc.). One which essentially no
> longer supports the primary description of the earlier product
> (program development for the Windows platforms), and shifts to
> development for a new, large (20MB) virtual platform. And oh, yes...
> even that will not run on millions of consumer (and to a lesser extent,
> business) machines.
>
> And on top of that, we see irresponsible enthusiasts claiming that it
> is "better" than the old tools for producing *any and all* kinds of
> software - a proposition that is blatantly untrue.
>
> > Be happy. Write some **** code.
>
> We are writing plenty of code - much of it in the areas for which VS.NET
> is clearly unsuited. For instance, a program which (on consumer systems
> under Win95/98/ME - no XP yet) monitors a group of analog sensors, doing
> real-time DSP and displaying/graphing selectable frequency responses.
> The project also required that we create the drivers for the sensor
> interfaces (obviously not a VB portion of the project). Hardly a "Hello
> World" project, but one well suited to VS6 and our non-OOP design style.
>
> Another recent one performs and evaluates certain forms of psychometry,
> graphing responses against certain "norms" and reporting various other
> relevant results.
>
> Generally speaking, our programs are response-time sensitive and do
> not involve internet/intranet communications or large scale databases.
> They run to the low tens of thousands of lines (if that) rather than
> the hundreds of thousands. They often have to run on old hardware,
> under consumer OSs (Win95 and up). They are modular, but not OO. And
> they are produced quickly and effectively.
>
> --
>
> W.E. (Bill) Goodrich, PhD
>
> *-----------------------*--------------------------------------------*
> * CHANGE YOUR SEXUALITY * http://www.nyx.net/~bgoodric/ctg.html *
> * * *
> * Without Aversive * ctgcentral@earthlink.net *
> * Behavior Modification * Creative Technology Group *
> * or Drugs * PO Box 286 *
> * * Englewood, CO 80151-0286 *
> *-----------------------*--------------------------------------------*

[Karl E. Peterson]

Hi Pat --

> Misunderstood your original post. I thought you were saying that Bill took
> credit for the "demise" of the language. That wasn't your point, so my
> apologies.

Yeah, even if he did have the balls to take credit for that, I couldn't grant him the
power to do that single-handedly regardless. He definitely contributed to it,
though, and seems proud of that based on cited interview(s).

Later... Karl
--
[Microsoft Basic: 1976-2001, RIP]

[Bill Storage]

Karl-

You're about 6 standard deviations off the mean in the world of VB
programming. Your technical skill is not in doubt, but you appear to be
without a clue of what commercial development with a big team of coders is
about, yet you claim very strongly to know what will "hose so many
customers". You boasted a few years back of having never done data access in
VB, at a time when the VBPJ poll showed the vast majority of apps were
database-centric. I respect your opinion that VB7 was a wrong move from your
perspective. We won't know for a while, but I suspect you are in the
minority.

It also seems that you're doing everything you can do to convince VB
customers to switch to another product (e.g., an eWeek article). Talk
yourself out of a job, but don't take me down with you. Are you expecting
that if you ***** loud enough, Microsoft might change their minds and roll
it all back?

Let's remember this discussion, and revisit it in a couple years.

Bill


"Karl E. Peterson" <karl@mvps.org> wrote in message
news:3c744a83$1@10.1.10.29...
> Hi Pat --
>
> > >> Yeah, especially after the .notters blamed him for single-handedly
> > causing the demise of VB6.
> >
> > I think he was simply quoted as taking credit for that. If you feel
> > otherwise, can you provide a cite?<<
> >
> > That's BS, Karl.
>
> What is? That the ".notters" blame Bill for destroying the language? Of
course it
> is, that's why I asked for a cite.
>
> But the article you reference pretty clearly makes the case that he was
all in favor
> of busting the **** outta the langauge, and to date he's the only one
willing to
> stand up and state it without hesitation. That's "taking credit" in the
books of
> many. Certainly trying to make it appear that his voice had an influence
on the
> ultimate decision to hose so many customers.
>
> > [Paraphrasing, of course] He was quoted as saying that backward
> > compatability has longterm costs that are often missed or ignored, and
that
> > it's cheaper in the long run to break compatibility in *some* cases.
>
> Too bad he didn't do the responsible thing, and advocate for a new
language that more
> closely met his needs, rather than trying to represent the costs for
millions of
> others.
>
> > Extrapolating that to him being the cause of VB6's alleged demise is
just
> > hyperbole. Fun, maybe, but not very nice.
>
> As I said, I'd like a citation for that extrapolation. So far, it's only
> cheerleaders that even suggest such a charge has been leveled. If you're
arguing
> with them, well, by all means carry on.
>
> Later... Karl
> --
> [Microsoft Basic: 1976-2001, RIP]
>

[Bob O`Bob]

Bill Storage wrote:
>
> Let's remember this discussion, and revisit it in a couple years.
>

Sucker bet.
If dotnet falls apart, this forum will cease to exist long before that.



Bob O`Bob
--
posting from work, but representing only myself

[Phil Weber]

> If dotnet falls apart, this forum will cease to exist
> long before that.

Bob: Karl and Bill will likely continue to exist regardless of the fate of
this forum, and will probably be able to find a way to contact each other.
;-)
---
Phil Weber

[Dan Barclay]

On Wed, 20 Feb 2002 18:26:49 -0800, "Bill Storage"
<storage@bplusmylastname.com> wrote:
>
>You're about 6 standard deviations off the mean in the world of VB
>programming.

LOL

>Your technical skill is not in doubt,

Likewise.

>but you appear to be
>without a clue of what commercial development with a big team of coders is
>about, yet you claim very strongly to know what will "hose so many
>customers".

Just how many of the 3,4,5 or 6 million (pick your number) VB
developers do you think program in a big team (larger than 3).

Let's not start arguing about who's 6 standard deviations off the
mean. There's a very large spread when the issue is "what is a VB
developer". If you think you represent something down the middle,
you're wrong.

Dan

Language Stability is a *feature* I wish VB had!
(#6)

[Zane Thomas [.NET MVP]]

On Wed, 20 Feb 2002 18:49:57 -0800, Bob O`Bob <bob@cluestick.org> wrote:

>If dotnet falls apart, this forum will cease to exist long before that.

But there will always be an OffRamp - somewhere in cyberspace. ;-)


--
When freedom is outlawed
only outlaws will be free.

[Zane Thomas [.NET MVP]]

On Wed, 20 Feb 2002 18:10:45 -0800, "Bill Storage"
<storage@bplusmylastname.com> wrote:

>This is more detail than I intended to get into

It's Mr. PhD's "pile on the bullshit" approach to "discussion".


--
When freedom is outlawed
only outlaws will be free.