.NET equals Efficiency - Page 2


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 2 of 11 FirstFirst 1234 ... LastLast
Results 16 to 30 of 151

Thread: .NET equals Efficiency

  1. #16
    Kathleen \(MS MVP\) Guest

    Re: .NET equals Efficiency

    Bill,

    Good to see you drop round.

    Thanks very much for some hard numbers!

    Kathleen



  2. #17
    Patrick Meader Guest

    Re: .NET equals Efficiency

    >> 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





  3. #18
    Phil Weber Guest

    Re: .NET equals Efficiency

    > 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



  4. #19
    Patrick Meader Guest

    Re: .NET equals Efficiency

    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!




  5. #20
    W.E.(Bill) Goodrich, PhD Guest

    Re: .NET equals Efficiency

    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 *
    *-----------------------*--------------------------------------------*

  6. #21
    Karl E. Peterson Guest

    Re: .NET equals Efficiency

    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]


  7. #22
    Patrick Meader Guest

    Re: .NET equals Efficiency

    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.





  8. #23
    Bill Storage Guest

    Re: .NET equals Efficiency

    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 *
    > *-----------------------*--------------------------------------------*




  9. #24
    Karl E. Peterson Guest

    Re: .NET equals Efficiency

    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]


  10. #25
    Bill Storage Guest

    Re: .NET equals Efficiency

    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]
    >




  11. #26
    Bob O`Bob Guest

    Re: .NET equals Efficiency

    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

  12. #27
    Phil Weber Guest

    Re: .NET equals Efficiency

    > 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



  13. #28
    Dan Barclay Guest

    Re: .NET equals Efficiency

    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)

  14. #29
    Zane Thomas [.NET MVP] Guest

    Re: .NET equals Efficiency

    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.

  15. #30
    Zane Thomas [.NET MVP] Guest

    Re: .NET equals Efficiency

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center