ExcelBanter - View Single Post - PLEASE READ IF YOU PROGRAM: Help Continue Visual Basic

Harlan Grove

wrote...
Microsoft needs to fix bugs.

Semantics. No question that they *SHOULD* fix bugs. Lord knows there
are lots of very longstanding bugs in Excel. Problem may be that these
bugs have been around so long that the Excel programmers may consider
them 'features' at this point.

But the only thing Microsoft *NEEDS* to do is earn money. If they can
rake in revenues without fixing bugs, why would they bother? One thing
that must be recognized about Microsoft: no matter how nice & upright
some Microsoft employees may be, Microsoft's corporate culture is, to
be charitable, amoral. Microsoft as an organization is oblivious to
'should' or 'ought'.

they need to raise the bar.

that is all i got fired for saying.

No doubt. Clearly you failed to appreciate the Microsoft's core
corporate cultu MAKING MONEY COMES FIRST, making decent software is
at best secondary.

it's ridiculous to fire a strong coder whose only fault is speakign the truth.

Nope. There are lots of strong coders. You're among the few who seem
not to combine (claimed) programming ability with discretion or the
sense to know what's important to your bosses.

it's ridiculous that there aren't more people that complain about things.

Inside Microsoft? Presumably the people who work for Microsoft want to
do so, and most of them realize when to shut up in order to continue to
do so.

Outside Microsoft? Do you read the newsgroups? There are frequent
complaints.

and i think that it's riduclous that you're sitting there trying to
tell spreadsheet newbies to run out and learn perl, python; all that
....

When? I've said I use perl. I've said Python is closely tied into
Gnumeric and OpenOffice Calc. I could add that it's possible to use
both (and REXX and Ruby and any other scripting language capable of
Automation) to automate Excel as a background process (though I'll
admit Excel as a background is a huge waste of resources). And I'll
repeat that there's a perl module that allows perl to create and modify
..XLS files without using Excel.

I've responded to unsubstantiated assertions you've made about how
wide-spread you believe VB, VBA and VBS code is. There may be a fair
amount of in-house VB apps in most medium to large corporations, and
there's definitely a lot of VBA code many extant Office document files.
There doesn't seem to be as much VBS code in use. I can't find any
definitive surveys on the most widely used scripting languages, but
from what digging I have done, it seems clear that a very small
fraction at most of web servers running Apache (so about 70% of all web
servers) would be running VBS code.

All of that's beside the point. Nearly all the people who post in
newsgroups for one or the other of the Office applications are looking
for solutions using those applications. VBA is often but not always
relevant, and it's certainly the best scripting language to use with
Office apps because it's built into the Office framework. VB proper and
VBS are mostly irrelevant for Office apps, though .DLLs could be
written in VB and VBS scripts could be added to Office app-generated
HTML files, but neither of those relatively esoteric tasks are relevant
to the vast majority of postings in Office app newsgroups.

Back to the original topic of this thread. VBA's future lifetime is
independent of that of VB6. Microsoft isn't foolish enough to kill off
VBA any time soon, and it'd offer its successor scripting language
(C#A?) as a parallel option for a few version cycles before it'd drop
VBA. So it's hard to see why people writing strictly VBA code for
Office apps should be any more concerned about the fate of VB6 than
that of COBOL. Similarly for VBS - it's use and future lifecycle are
independent of that of VB6.

So it comes down to whether Microsoft revives a VB6-like programming
language. As I've already written, to in-house VB coders who've already
switched to VB.Net (and they've done so in my company) reviving VB6 is
either an irrelevance or an annoyance. It's no longer an alternative.
Microsoft won't win points with or receive revenues from such customers
by reviving VB6. I have no idea what share of former VB6 programmers
have moved on to VB.Net, but if it's more than half, then A Dios VB6,
it was nice knowin' ya.

I'll also repeat that this is what could happen when one relies on
proprietary software. VB6 programmers who believed that Microsoft would
always be there to support them have no one but themselves to blame for
their own naivete. I won't stand in the way of their petition drive to
keep VB6 alive, but I believe it'll be as efficacious and writing Santa
Claus.