Re: Over 100 Microsoft MVPs Have Signed Online Petition - Give Us Back VB!!


"Richard Grossman" <rgrossmanDELETE-THIS-PART@xxxxxxxxxxx> wrote in message
news:424cea92$1@xxxxxxxxxxxxxxxxxxxxxxxxx
> Dan Barclay wrote:
>> Just pointing out an obvious fact. You were trying to attribute the
>> things you didn't like to lack of development or resources.
>
> I don't think I was - and if I did, I was wrong <g>. Because like you
> say:
>
>> My points stands that MS tools are not development or resource limited,
>> they're just targeted at something other than the developer market.
>
> Meanwhile:
>
>> I was talking about the MS data controls. They're not "VB". Still, even
>> though you could, why would you want to use them in Delphi?
>
> Now I'm totally confused. I was talking about the VB data controls. Why
> are they not VB?

What I'm trying to say is that they are a library and are not a part of the
core language. My prime interest is *language* stability (e.g. MSBasic).
Product stability is important, but not nearly as important. See the
specifics of terms the way I'm trying to use them here under "What does it
mean?": http://www.vb.mvps.org/tips/stability.asp

"VB data controls" are com controls, in an ocx. That's all. You can
include them (or not) in your tool bar.

> I wouldn't ever want to use them in Delphi - or in VB; the VB controls are
> all broken.

Ayup.

> Yet the data controls in Delphi work great - I use them all the time.

Great. Dunno if I will, but then I don't do a lot of DataStuff. I'm a Code
kinda guy.

>> know what crowd you hang with. My code breaks down quite a bit
>> differently. I have a handful of forms, no data controls. I've got about
>> 3 1/2 megs of code (Subs and Functions, not including classes or forms
>> etc). I've got (surprise) an interpreter and UI generator built in
>> Basic. My data engine is pluggable, allowing my users to select MDB's
>> or Btrieve as a base.
>
> Your coding efforts in VB then are brilliant in their amazing extension of
> VB.

Nope. I'm just a dumb ol' country boy. Give a monkey a typewriter, etc.

> (It will be bittersweet to find out in one either wouldn't need it, could
> download it free, or buy it inexpensively in Delphi universe. See the
> 3rd-party newsgroup.)

Wouldn't need what?

> More importantly though: Do you think you've gotten a dollar return on
> that investment?

Absolutely! Remember, I got in this game when Basic *was* stable. Our
first products were available on TRSDOS and CP/M. I had to make a 6 hour
drive to Dallas to get my first IBM/PC.

> I think the problem is that the recent obsolescence of VB6 by Microsoft is
> leaving you with a large codebase investment that can no longer be
> leveraged.

Yes, except that I do know how to migrate. I know what to look for in a
target platform, and in the tools to get there. I can get to Delphi. The
thing is, I'd like it to be easier (and more comfortable) so that tons of
others can get here as well. It's to *all* our advantage to make sure
Delphi is what I call a "healthy" environment (base company as well as tools
vendors).

VB (and the other MSBasic products before it) is actually an excellent tool
for vertical applications by small shops. A lot of these shops were started
by folks with good development skills (if not formal training), but with a
*lot* of subject matter knowledge. Typically they came out of the
industries they now serve as ISV's. They learned MSBasic because it was on
their machine and they had a job to do.

I don't know if you remember the earlier days, but Basic was about the only
language that was "string friendly". Now most languages have learned the
importance of that and include that functionality. BStr's aren't called
that for nothing.

Basic was "managed code" before that was cool... except you had a rip cord
to break out if you wanted to. If you wrote code using pure core language,
even as far back as CP/M, you didn't have to worry about memory management
(allocation, pointers, etc).

> The same thing happened to me when FoxPro 2.6 was obsoleted by Microsoft
> with a new version that wouldn't compile the old code. I had a huge
> library of stuff that made FoxPro do things it could never do out of the
> box.
>
> I vowed never to do that again.
>
> I'd rather spend 25 to 350 bucks on a component (set) and let a component
> developer spread the time investment over many customers.

Absolutely correct! I don't do "cute" stuff in my own code any more. At
one time I had to, and I had a fairly large librarary of low level, but
important, functions built in MASM. During the DOS era, vendors started
showing up at the party with those "off the shelf".

My code is core to the app, business logic that is focused on the market I
serve.

>>>That covers 90 % of all VB apps. And another 9 % are glue apps and glue
>>>code within apps that support VB scripting. Only a small % of VB is used
>>>for anything else because Java, C, and Delphi are much better choices in
>>>most cases.
>>
>>
>> LOL. Where do you get your data? That doesn't represent the crowd I'm
>> familiar with. I don't know a serious VB app in which the dev trusts
>> data controls as far as he can throw them.
>
> Or a non-serious VB app - because even if the dev trusted them to start
> with, they wouldn't work.
>
> But still, 90% of all VB apps are data apps (and I didn't say VB "data
> control" apps).

I don't think that's right (unless you're talking about apps that just use a
database). Most of the important apps I'm familiar with *process* data in a
complex way. Heck, I use databases to store results and log things but it's
way down on the food chain functionally speaking.

>>>>Those guys are just not associated with the product any more
>
> And the culture was not passed on, apparently.

Nope. Discussions with them have been quite... amazing. It would be like
me being in charge of Delphi and claiming I had the background to manage it.
Hell, I'd love to get the reins<vbg> but at least I know I'm clueless on a
few things. These guys actually believe, to this very day, that they know
what they're doing.

Either they are putting on an incredible act in convincing us of their
belief, or they are incredibly arrogant.

>>>I've personally been down this road and it's too long a story for here.
>>>But based on my experience, Microsoft will put an evangelist (those are
>>>the people who tell you the company is "fully committed" to the
>>>technology you like) out there to front for the company, but the
>>>evangelist is no indicator at all of where Microsoft might actually be
>>>going.
>>
>> You are exactly right regarding the evangelist strategy.
>
> Yeah, every once in awhile I get one right <g>.
>
>> However, that's not the folk I'm talking about. I was meeting with the
>> "behind the firewall" developers...
> ..
>> Heck, for Christmas that year they even sent me a VB4 box (the big box)
>> autographed by all the VB developer team. There are a bunch of them<g>.
>
> Good story.
>
>> But, like I said, when they cobbled together the VB7 team they pretty
>> much started over. The current crop of folks are completely different
>> and have very little background with either using VB or any previous
>> development on VB.
>
> This is standard operating procedure. There have even been stories
> claiming that iterative OS upgrades that had to be written from scratch
> because the original developers hadn't been retained.
>
>> I think you missed the point. I "prefer" End While as well. Others
>> don't. The point is that there was no *reason* to change it after it was
>> already established. So, if the next guy "prefers" Wend (or something
>> else) he's free to change it back again, eh?
>
> Oh, now you expect *reasons* from changing things, do ya? <g>

Hmmm... actually I expect them not to change at all<g>. A change in a
programing language should *never* be a surprise.

> Extending your earlier observation, they put a new team who had no idea of
> what it was like to actually develop in the language.

Correct. No idea what it was like, and no previous exposure to anyone who
knew what it was like. They did do some focus groups, but the guys they
called in had strange ideas about things. One, in particular, has had them
in his pocket for a while and they "thought" he knew what he was talking
about. Check this out, from an interview (the quote is on pg7 of the
interview):

"Drop backward compatibility altogether. Do us a favor; haven't you guys
learned the lesson of DOS? Backward compatibility cost us so much money over
the years. Break my code. Force me into getting rid of my old code if I want
to add VB7 features into my product." Bill Storage, VBPJ Author and
Microsoft Visual Basic MVP (1996-2000), recalled in VBPJ
"Do you guys realize what you're telling us? I mean, we're flabbergasted. We
can't believe what we're hearing." Yuval Neeman, Corporate Vice
President/Developer Division (Microsoft), reaction in VBPJ

But, they did it anyway! More quotes at http://vb.mvps.org/vfred/Trust.asp
(over over some of the links for more comment<g>).


>> In addition, they've acutally *reused* keywords. No deprecation, just
>> killed features and reused keywords. For example, in returning values
>> from functions they could have extended the existing syntax by using
>> "Exit Function <retValue>". Instead, they used the Return keyword. Why?
>> Because the devs had a C background and not a Basic background. They
>> simply didn't have the background to do it in a "language consistent"
>> way.
>
> Or... cough-cough ... maybe one of the development managers had a Delphi
> background... ahem... can't think of who though... <clears throat>.
> <g>


Nope, he wasn't involved in language decisions. He had other fish to fry.

>> One of the things that has really ticked me off at MS is that they
>> convinced me in the previously discussed meetings that they *did* intend
>> to treat VB as a real developer tool. You may or may not be aware of the
>> internal politics of the time but VB was moved between the applications
>> and languages group a couple of times. We were involved in those
>> "discussions".
>>
>> Putting a native compiler back in VB, along with a lot of assurances,
>> made me feel comfortable recommending VB again, and I did. I've had to
>> apologize to some folks for that.
>
> We all get burned - you did what you thought best at the time.


"burned"... you misspelled a word, but the proper spelling doesn't belong in
a family ng<g>.

>
>>> Because I always knew they would.
>>
>>
>> Then you were psychic. For MS to leave behind such a huge crowd of
>> developers, locked into their *proprietary* language is idiotic, even for
>> MS. It was completely unexpected by *anyone* who knows anything about
>> MS or even raw marketing. FWIW, MS didn't *intend* for this to happen.
>> They were as shocked as anyone.
>
> Only through a similar painful experience over FoxPro.


Most of us discounted the Foxpro thing, rationalizing that Basic was
different because that's what the company was built on. And, seriously, it
was.

>
>> For the record, it's "forward compatibility", not "backwards". From
>> *our* perspective as users, we want our code assets to be forward
>> compatible.
>
> Makes sense - never heard it that way though - usually we think "backwards
> compatibility" because that's a feature of an upgrade version - that it's
> "backwards compatible" with code written in prior versions.


If we call it "forward", maybe we can get the vendors to start thinking in
*our* terms.

> I guess "backwards compatibility" is a feature and "forwards
> compatibility" is a promise.
>
>> "post-RAD" WTF is that!
>
> Just made it up just then, actually.


Oh. From your description, it sounds like a formula for failure. I can
only hope my competitors buy into it hook, line, and sinker<vbg>.

>
>> With a long lived app you need to be planning and moving with the long
>> term in mind. The objective is to deliver the app to your customer base.
>> The task is to do that on a platform your users will have. If you wait
>> until your app won't run on a new OS to do anything about it your
>> business is dead.
>
> No, the users can just stick with the old OS. That's not actually my
> approach, but it works for lots of products out there.


That can work for products that "own the machine", like a POS system. Most
of us have products that much live on machines that does other things for
the user. Those must move forward at some point.

>> Oh, wait. I forgot that you build thin apps. You can probably do that
>> in a long weekend.
>
> <g>

Sorry, but you lobbed that one my way and I had to take a swing<g>.

> I think you had called it "thin covers over data". I do "thin covers over
> data", but it covers a lot of data, and as much of the intelligence is in
> the database design as possible.
>
> Meanwhile, the core areas of the application are heavily designed to
> present complex data in an understandable and manageable way.
>
> One can handle complex requirements with sophisticated arrangements of
> *simple* parts.
>
>> "Nothing upsets [the VB dev team] more than when they see the negative
>> things on the newsgroups and the negative people slamming their product.
>> These guys just don't sleep at night, they're so bummed about it." Dave
>> Mendlen, Lead Product Manager for Visual Studio.NET (Microsoft), Love, VB
>> Style, VBPJ, August 2001 "
>
> Nice PR.

LOL. It sure hit dead air. When you compare "Bummed out" with "Screwed"
they come off as a bunch of whiners.


>> Not in this case. It's done. We didn't get a Ressurection at Easter<g>.
>> Another quote from the page above:
>>
>> "It's over. There's nothing left for you here. Wake up. Go home. Your
>> children are waiting." Bruce McKinney, Noted Visual Basic Author, The
>> End of Hardcore Visual Basic
>
> Like I said, I went through this same emotional process with FoxPro.
>
> The days of religious fervor and total language immersion ended for me in
> the early 90's.
>
> I guess the "music died" for you in the last year or two.
>
> But there will be another generation coming up and they will embrace the
> next great solution to everything.


Possibly, but the ones who are going to be successful will look for the same
important attributes that we looked for. I've had enough "inside" contact
to know that it's been over for quite a while. That's why we are where we
are with Delphi. Others are just noticing that it's real. VB will continue
to be a decent development environment for a little while. When that
changes, the rest will wake up.

I can say that this petition is a good "last shot at it". It would have
been interesting if we could seriously have awakened MS. Discussions are
still going on, but it's not going to happen IMHO. Given what's happened in
the last 4 years, it would take a real shakeup to regain the lost trust even
if they found a way to migrate some code for us. Trust does matter, at
least to the folks with code assets. Your case is a good example.

> I remember telling my mainframe-coding uncle about how PC's were
> practically the savior of mankind and that he was a dying breed. Meanwhile
> he was working on the first ATM-development team.
>
> And he knew enough just to smile quietly at my proselytizing.
>
> But we must all grow past the disillusion, grasshopper <g>.

Don't confuse my hell raising with hope<g>. I know the score, and I have
for a very long time.

Dan




.

Relevant Pages

  • Re: Over 100 Microsoft MVPs Have Signed Online Petition - Give Us Back VB!!
    ... > They work *great* in Delphi. ... I don't know a serious VB app in which the dev trusts data ... They did do a good job on VB6, with regard to language stability and moving ... Good luck in lobbying for VB.net compatibility. ...
    (borland.public.delphi.non-technical)
  • Re: Looking for BASIC compiler
    ... >> It's not that the language itself is that bad, ... >> if there was a solution not requiring runtimes, ... >>> as easy to get going as a VB app. ... >> I like Delphi, but would prefer a BASIC solution to no runtimes ...
    (comp.lang.basic.misc)
  • Re: Visual Basic for Autorun?
    ... As our app is large, complex and well developed we would be loath to start ... > Use another language, seriously. ... > would take no time to write something in delphi or maybe C as most autorun ...
    (microsoft.public.vb.general.discussion)
  • Re: What programming language for Future
    ... > D is a pretty young language. ... app is being tweaked by an end user). ... all this is not really possible with static compilation. ... there is also a gcc implementation of ada. ...
    (comp.lang.misc)
  • Re: VB6, VB2005, or Something Else?
    ... up" the language rather than any requirement of the platform change. ... the site seems to have articles from Borland too. ... don't understand is that you are moving completely to Delphi. ... including a fundamental data type. ...
    (microsoft.public.vb.general.discussion)