Self-Interest & VS.NET

[James D. Foxall]

I AM NOT ALONE!!!! <vbg>

--

James D. Foxall
Microsoft Certified Solution Developer

"Vlad Ivanov" <vivanov@polarisconsulting.com> wrote in message
news:3a771b17@news.devx.com...
> I posted very similar message long time ago. I guess you and me are
> exceptions to this "just leave it in VB6, it works" practice that the
> .Net-kiddies are preaching. I am all for the evolution, i lke dontnet, but
i
> think Microsoft demonstrates a blatant disregard for "codebases" of their
> users. And the "migration wizard" excuse doesn't cut it.
>
>
> "James D. Foxall" <jamesf@tigerpawsoftware.com> wrote in message
> news:3a7713ee$1@news.devx.com...
> > Sorry Jonathon, I must have not made myself clear, or you didn't
> understand.
> >
> > > I too have some legacy apps.
> >
> > This is not a legacy app - geesh! This is a commercial application that
> goes
> > through annual revs. Microsoft doesn't rewrite every office app from
> > scratch, they build on what they had before. Why is it so hard for
people
> to
> > imagine having a continually evolving code base? Is everyone else
building
> > projects on a consulting bases and then moving on? If you're developing
> > shrink-wrapped products, you move your code base forward - it evolves.
> >
> > > Good, then you won't need to port it to VB.Net.
> >
> > Huh? How will we continue to evolve our product over the years, giving
our
> > customers the features they require, if we continue to use a dead
language
> > (VB6)? We will eventually have to move it to <something>.
> >
> > --
> >
>
>
>

[Mark Burns]

"James D. Foxall" <jamesf@tigerpawsoftware.com> wrote in message
news:3a77141c$1@news.devx.com...
> "Mark Burns" <mark@iolofpa.com> wrote in message
> news:3a75f1d6@news.devx.com...
> > So...that sounds like a "yes" sort of response....?<g> <maneuvering to
pin
> > ya into that corner _really good_ this time...<g>>
>
> Getting closer to a 'yes' I'd say.
>
> How about that? <g>

Close, but...<and having said that I dangle before you the Platinum-Level
".Not-er" membership medallion...> ...just a leeeeetle closer, and...<g>

[Mark Burns]

"James D. Foxall" <jamesf@tigerpawsoftware.com> wrote in message
news:3a771bde$1@news.devx.com...
> I AM NOT ALONE!!!! <vbg>

**** no!...<as if you couldn't tell...<g>>

[James D. Foxall]

Platinum??? er...

--

James D. Foxall
Microsoft Certified Solution Developer

"Mark Burns" <mark@iolofpa.com> wrote in message
news:3a773f6d@news.devx.com...
>
> "James D. Foxall" <jamesf@tigerpawsoftware.com> wrote in message
> news:3a77141c$1@news.devx.com...
> > "Mark Burns" <mark@iolofpa.com> wrote in message
> > news:3a75f1d6@news.devx.com...
> > > So...that sounds like a "yes" sort of response....?<g> <maneuvering to
> pin
> > > ya into that corner _really good_ this time...<g>>
> >
> > Getting closer to a 'yes' I'd say.
> >
> > How about that? <g>
>
> Close, but...<and having said that I dangle before you the Platinum-Level
> ".Not-er" membership medallion...> ...just a leeeeetle closer, and...<g>
>
>

[Jonathan Allen]

If I were you James, I would lie low until that post expires.

--
Jonathan Allen


"Patrick Steele" <psteele@ipdsolution.com_> wrote in message
news:MPG.14e0df0944bfa2fc989699@news.devx.com...
> In article <3a771289@news.devx.com>, jamesf@tigerpawsoftware.com says...
> > **** spell checker. What the **** does effeminately mean anyway? <g>
>
> http://www.dictionary.com/cgi-bin/di...m=effeminately
>
> "1. Having qualities or characteristics more often associated with women
> than men."
>
> "2. Characterized by weakness and excessive refinement"
>
> Hmmm....
>
> --
> Patrick Steele
> (psteele@ipdsolution.com)
> Lead Software Architect

[Jonathan Allen]

> This is not a legacy app - geesh! This is a commercial application that
goes
> through annual revs.

> How will we continue to evolve our product over the years, giving our
> customers the features they require, if we continue to use a dead language
> (VB6)?

VB6 isn't disappearing at midnight. As long the features they ask for is
within the capabilities of VB6, you can continue to use it. I have an active
project in VB6 that I intend to add functionality to for at least the next
few years. Since it was designed with VB6 in mind, all the features planned
for it will work just fine.

You are acting like you can't touch your project once VB.Net is released,
which is nonsense. There is no reason why you can't continue to use VB6 to
support and expand existing projects, In fact, you can even create new
projects in VB6 if you want to.

--
Jonathan Allen


"James D. Foxall" <jamesf@tigerpawsoftware.com> wrote in message
news:3a7713ee$1@news.devx.com...
> Sorry Jonathon, I must have not made myself clear, or you didn't
understand.
>
> > I too have some legacy apps.
>
> This is not a legacy app - geesh! This is a commercial application that
goes
> through annual revs. Microsoft doesn't rewrite every office app from
> scratch, they build on what they had before. Why is it so hard for people
to
> imagine having a continually evolving code base? Is everyone else building
> projects on a consulting bases and then moving on? If you're developing
> shrink-wrapped products, you move your code base forward - it evolves.
>
> > Good, then you won't need to port it to VB.Net.
>
> Huh? How will we continue to evolve our product over the years, giving our
> customers the features they require, if we continue to use a dead language
> (VB6)? We will eventually have to move it to <something>.
>
> --
>
> James D. Foxall
> Microsoft Certified Solution Developer
>

[Mike Mitchell]

On Tue, 30 Jan 2001 13:19:29 -0600, "James D. Foxall"
<jamesf@tigerpawsoftware.com> wrote:

>**** spell checker. What the **** does effeminately mean anyway? <g>
>
What happens when you allow your neighbour's pit bull terrier to get
too close...

MM

[Mike Mitchell]

On Tue, 30 Jan 2001 10:10:18 -0800, "Jonathan Allen"
<greywolfcs@bigfoot.com> wrote:

>> To say the whole language needed to be trashed and started over is nuts.
>
>Maybe so, but some of us have been saying it for years.

Yes, some have. Around five million have not. Remember the figure: 60%
have never used a class. The great and silent majority have just
enjoyed using VB as the RAD tool of the millenniums (last and
current), and for those bored with structured programming and wanting
more, well, there have always been many other languages for them to
move into.

The changes have most definitely NOT happened because relatively few
programmers kept demanding inheritance and all the other OOP bloat
which BASIC was never, ever designed or intended to do. If any
programmer wanted to program the OOP way, then using the bolt-ons in
Classic VB was always a kludge, a cop-out. They always did have the
chance to move into true OOP languages like Java and Delphi. So why
didn't they do so, and allow the six million happy souls to continue
creating great solutions for their corporate employers in away that
worked for them?

>
>>That app works great, has a comparatively
>> low support requirement,
>
>Good, then you won't need to port it to VB.Net.

He explained exactly why he would need to move it into VB.NET at great
cost and at great risk of new bugs. Supposing an app has a life span
of twenty years. You don't want to develop it for, say, three years,
and then freeze it for seventeen. You want to add new functionality as
and when required. But there will inevitably come a time when VB6 is
no longer supported by Microsoft. Even if we could persuade Microsoft
to clarify just how long they are prepared to support it, sooner or
later they will cease to support it.

But your app is still working, still providing a solution to your
clients. Everything fine so far.

However, as life moves along on separate threads, your client upgrade
to .NET. Your app still carries on working, no problem. But then your
client starts wondering, if everything about this new .NET stuff is
great, why isn't Company XYZ (i.e. you) bringing me an updated
.NET-based version to take advantage of [insert benefits of .NET
here].

So you get a call one day from your client, who sounds a bit on edge,
and you ask him why, and he says, well, it's like this, we're using
your fabulous app and it hardly ever fails us, and it's great! So
(puzzled) you ask, yeah, so what's the problem? And your client says,
well we've gone over to .NET, but you haven't said anything about
providing a .NET-compatible app to replace the 'old' one. And you
chuckle and say, ah, it may be old, but it'll still work in
conjunction with .NET, so where's the problem? And your client says,
well, if there isn't a problem, why can't you just supply a .NET-based
version anyway? And sooner or later you'd have to tell him, or he'd
find out another way, that the app would have to be almost completely
rewritten if it were to be ported into .NET.

Your client is hardly going to be reassured by this news, is he? He
might have been planning to tender for a new, different app with you,
but is now doubtful that you're the right firm to do the job, if you
cannot move that 'old' app into the new paradigm. Okay, so *you* know
that you *could* do a new app in VB.NET, but how do you reassure your
client? On the one hand you have admitted that the 'old' app, though
working perfectly fine, is effectively frozen for ever - unless lots
of money changes hands; while on the other hand your client is
desperate to know whether he might be in bed with the wrong company
after all. And no matter how good you might be and how much you try to
convince your client that the mix of 'old' VB6 and new VB.NET is a
totally acceptable way to proceed, it's you who have to do the
convincing of HIM, not the other way around. And of course he has the
perfect right to decide to place that new app with another software
house. Said software house MIGHT EVEN do it in VB.NET, but the client
still feels happier to get the new app written by .NET specialists,
while still trusting you enough to carry on 'supporting' the old app.

This is but one scenario. There are many derivations.

MM

[Jason Kaczor]

kylix_is@hotmail.com (Mike Mitchell) wrote:

>Remember the figure: 60% have never used a class.

Is that Microsoft's fault?

Gee, I guess they are simply going to easily "switch" over to Delphi or Java,
right?

>which BASIC was never, ever designed or intended to do. If any
>programmer wanted to program the OOP way, then using the bolt-
>ons in Classic VB was always a kludge, a cop-out.

Correct. VB had a very poor OOP-graft. VB.NET get's it right.

>They always did have the chance to move into true OOP languages >like Java
and Delphi. So why didn't they do so, and allow the
>six million happy souls to continue creating great solutions
>for their corporate employers in away that worked for them?

Perhaps because their corporate employers prefer buying Microsoft tools?


For anyone who has used Delphi, there is no question of it's RAD capabilities.
For years it has had RAD features prior to VB (live data-bound designers?),
yes it has played catch-up in others (IntelliSense), but overall it is a
very clean syntax, suitable for all manner of RAD programming.

So why isn't it king? Why do we not have "beta" VCR's?

Where is PowerBuilder? Clarion?

At one point it was "kosher" and correct for companies to simply buy IBM
tools, software and services. In the last decade it was Microsoft. Maybe
in the next it will be Java/Sun/IBM.

>He explained exactly why he would need to move it into VB.NET
>at great cost and at great risk of new bugs.

Of course, "moving" something to a new platform is prone to error.

>Supposing an app has a life span of twenty years. You don't
>want to develop it for, say, three years, and then freeze it
>for seventeen.

Wow, you want a vendor to support a development environment, and toolset
for their own custom language for that long?

Welcome back COBOL.

>You want to add new functionality as and when required. But
>there will inevitably come a time when VB6 is no longer
>supported by Microsoft. Even if we could persuade Microsoft
>to clarify just how long they are prepared to support it,
>sooner or later they will cease to support it.

Correct, I'm sure in 20 years Sun/IBM/Java will have also "moved" on.

>But your app is still working, still providing a solution to
>your clients. Everything fine so far.

Who are meanwhile running "terminal-emulator" software to execute it on their
"256-bit" processors.

>But then your client starts wondering, if everything about this
>new .NET stuff is great, why isn't Company XYZ (i.e. you)
>bringing me an updated .NET-based version to take advantage of
>[insert benefits of .NET here].

20 years, and they haven't clued into the marketing speak. ****, my physician
knows what object-oriented programming is, NOW!

>So you get a call one day from your client, who sounds a bit on
>edge,and you ask him why, and he says, well, it's like this,
>we're using your fabulous app and it hardly ever fails us, and
>it's great! So (puzzled) you ask, yeah, so what's the problem?
>And your client says, well we've gone over to .NET, but you
>haven't said anything about providing a .NET-compatible app to
>replace the 'old' one. And you chuckle and say, ah, it may be
>old, but it'll still work in conjunction with .NET, so where's
>the problem? And your client says, well, if there isn't a
>problem, why can't you just supply a .NET-based version anyway?

Meanwhile, whilst you were twiddling your thumbs, looking to "current" revenue
stream rather than future, a competitor "cloned" your application in 6 monthes
using compatible "interfaces", OOD/OOA/OOP and "magic-bean-technology" (insert:
Java/.NET/etc.)

>And sooner or later you'd have to tell him, or he'd find out
>another way, that the app would have to be almost completely
>rewritten if it were to be ported into .NET.

Right. If they wanted a Unix/Mac/Solaris version, you'd have to PORT to
a new toolset/technology.

Customers aren't stupid, they have some idea that "change happens".

Gee, are these same clients still wonderring if that "internet thang" is
going to catch on?

>Your client is hardly going to be reassured by this news, is
>he? He might have been planning to tender for a new, different
>app with you, but is now doubtful that you're the right firm to
>do the job, if you cannot move that 'old' app into the new
>paradigm.

He'd have a point. My clients would ask to the numbers, the estimate. And
then determine if the cost would provide value.

>Okay, so *you* know that you *could* do a new app in
>VB.NET, but how do you reassure your client? On the one hand
>you have admitted that the 'old' app, though working perfectly
>fine, is effectively frozen for ever - unless lots of money
>changes hands;

What happens to apps that are already in place using "dead-technology", those
clients don't expect a "silver-bullet".

>while on the other hand your client is desperate to know
>whether he might be in bed with the wrong
>company after all.

If the company has no hard-data, estimates, tests or prototypes of VB6>.NET
ports, he'd be right. Perhaps this is why the .NET beta will be @1-year
in length.

>And no matter how good you might be and how
>much you try to convince your client that the mix of 'old' VB6
>and new VB.NET is a totally acceptable way to proceed,

Is it? What if Windows no longer becomes a viable platform, MS is just a
.NET vendor.

>it's you who have to do the convincing of HIM, not the other
>way around.

Well most clients that I know who expect a "product", do NOT care what language
it is written in. Those who demand an Enterprise solution are another story
completely.

>new app with another software house. Said software house MIGHT
>EVEN do it in VB.NET, but the client still feels happier to get
>the new app written by .NET specialists,while still trusting
>you enough to carry on 'supporting' the old app.

Lot of money in support. Except when the entity is replaced.

>This is but one scenario. There are many derivations.
>MM

Yep, client demands Java, Linux, Delphi, Web... If you haven't investigated
the alternatives already, are you really providing value to the client?

Regards
Jason Kaczor

[James D. Foxall]

Nah, that's what the <g> was for.

Besides, I'll be the first to admit I need a good editor to even write a
check! <vbg>

--

James


"Jonathan Allen" <greywolfcs@bigfoot.com> wrote in message
news:3a777088@news.devx.com...
> If I were you James, I would lie low until that post expires.
>
> --
> Jonathan Allen
>
>
> "Patrick Steele" <psteele@ipdsolution.com_> wrote in message
> news:MPG.14e0df0944bfa2fc989699@news.devx.com...
> > In article <3a771289@news.devx.com>, jamesf@tigerpawsoftware.com says...
> > > **** spell checker. What the **** does effeminately mean anyway? <g>
> >
> > http://www.dictionary.com/cgi-bin/di...m=effeminately
> >
> > "1. Having qualities or characteristics more often associated with women
> > than men."
> >
> > "2. Characterized by weakness and excessive refinement"
> >
> > Hmmm....
> >
> > --
> > Patrick Steele
> > (psteele@ipdsolution.com)
> > Lead Software Architect
>
>

[James D. Foxall]

Sounds good in theory, and in truth we may have to.

However...

1. Advances in components will move away from ActiveX components. We use
over a dozen of these, so we may be unable to get fixes, and may not be able
to upgrade to take advantage of functionality.
2. It will be harder to implement technology related features because the
tool won't support them.
3. Interfaces change. For instance, the Open File dialog box is different
in 16-bit and 32-bit - users can see the difference. As other applications
move forward with new components and features, it starts to become obvious
when you haven't.
4 Stability features. As new software and OSs come out, you are more
likely to encounter new problems. For instance, we're getting ready for the
Alpha release of a VB6 product. We have a whopper of a problem right now in
that doing a certain action causes the machine to eat 125 MEG of ram in
about 2 seconds!!! At times, you can do it again and eat another 125 MEG
(that's MEG!) and grind the machine to a halt. We'll find and fix this (but
haven't had luck so far), but the real interesting part is that this app
doesn't have the problem on a 98 machine, but does on NT and 2000 machines.
Our problem? Microsoft's problem? The fact is, a language that isn't
maintained runs the risk of having new problems with each no OS, service
pack, and component update.

There are more issues of course. I just wanted to list some of the issues
that show how this is risky.


--

James D. Foxall
Microsoft Certified Solution Developer
Vice President - Tigerpaw Software (MCSP) www.tigerpawsoftware.com


"Jonathan Allen" <greywolfcs@bigfoot.com> wrote in message
news:3a777089@news.devx.com...
> > This is not a legacy app - geesh! This is a commercial application that
> goes
> > through annual revs.
>
> > How will we continue to evolve our product over the years, giving our
> > customers the features they require, if we continue to use a dead
language
> > (VB6)?
>
> VB6 isn't disappearing at midnight. As long the features they ask for is
> within the capabilities of VB6, you can continue to use it. I have an
active
> project in VB6 that I intend to add functionality to for at least the next
> few years. Since it was designed with VB6 in mind, all the features
planned
> for it will work just fine.
>
> You are acting like you can't touch your project once VB.Net is released,
> which is nonsense. There is no reason why you can't continue to use VB6 to
> support and expand existing projects, In fact, you can even create new
> projects in VB6 if you want to.
>
> --
> Jonathan Allen
>
>
> "James D. Foxall" <jamesf@tigerpawsoftware.com> wrote in message
> news:3a7713ee$1@news.devx.com...
> > Sorry Jonathon, I must have not made myself clear, or you didn't
> understand.
> >
> > > I too have some legacy apps.
> >
> > This is not a legacy app - geesh! This is a commercial application that
> goes
> > through annual revs. Microsoft doesn't rewrite every office app from
> > scratch, they build on what they had before. Why is it so hard for
people
> to
> > imagine having a continually evolving code base? Is everyone else
building
> > projects on a consulting bases and then moving on? If you're developing
> > shrink-wrapped products, you move your code base forward - it evolves.
> >
> > > Good, then you won't need to port it to VB.Net.
> >
> > Huh? How will we continue to evolve our product over the years, giving
our
> > customers the features they require, if we continue to use a dead
language
> > (VB6)? We will eventually have to move it to <something>.
> >
> > --
> >
> > James D. Foxall
> > Microsoft Certified Solution Developer
> >
>
>
>

[Mark Burns]

"James D. Foxall" <jamesf@tigerpawsoftware.com> wrote in message
news:3a783650$1@news.devx.com...
>
> There are more issues of course. I just wanted to list some of the issues
> that show how this is risky.

"risky"? Wow! ...talk about your understatements<g>.
I think you misspelled "fraught with peril"<g> HTH.

[James D. Foxall]

--

James

"Mark Burns" <mark@iolofpa.com> wrote in message
news:3a7843cc@news.devx.com...
>
> "James D. Foxall" <jamesf@tigerpawsoftware.com> wrote in message
> news:3a783650$1@news.devx.com...
> >
> > There are more issues of course. I just wanted to list some of the
issues
> > that show how this is risky.
>
> "risky"? Wow! ...talk about your understatements<g>.
> I think you misspelled "fraught with peril"<g> HTH.
>
>
>