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


"Richard Grossman" <rgrossmanDELETE-THIS-PART@xxxxxxxxxxx> wrote in message
news:424c226a$1@xxxxxxxxxxxxxxxxxxxxxxxxx
> Dan Barclay wrote:
>> The thing is, MS tools aren't targeted to the developers' needs, they're
>> positioned to push other MS objectives. Their purpose is to sell
>> platforms and Office, which is where MS makes its money.
>
> Oh, so MS products are designed to maximize shareholder value - radical
> insight!

Just pointing out an obvious fact. You were trying to attribute the things
you didn't like to lack of development or resources. My points stands that
MS tools are not development or resource limited, they're just targeted at
something other than the developer market.

>> Beats the hell outta me. I don't use data controls (again, those are
>> libs and you could as easily use them from other that VB I think). If I
>> want data I write a function and return what I want.
>
> They work *great* in Delphi. It's this little thing we call RAD...

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?

>> Likewise most of the serious apps I know aren't thin data covers.
>
> <groan>
>
> Unfortunately, in this you are no different than the typical Delphi
> programmer who frequents this forum.
>
> 90% of any app I write is a "thin" data cover. If done right, the
> intelligence is in the database design.

Ahhh... I'm beginning to understand some things now.

> And the last 10% covers a few "heart of the system" screens that use data
> controls in the most creative way possible to both present data in a
> meaningful way and allow the user to act on it.

Many of the devs I know of, and their apps, are just the opposite. I don't
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.

But, then, maybe you consider all that to be a thin data cover.

>> I simply don't know if VB is good for that or not, it could be.
>
> 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.

I think you stayed in silly valley a bit too long during that dotcom era.

<snip>
>> Actually, the folks I met with *were* on the right track. They were also
>> "the right folks". That's why they agreed to put a native compiler back
>> in the product, along with a bunch of other stuff. It was no accident
>> that it happened at VB5. Those guys are just not associated with the
>> product any more (see other discussion here about MS's propensity to move
>> people).
>
> 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.

However, that's not the folk I'm talking about. I was meeting with the
"behind the firewall" developers. The meetings I'm talking about were
preAlphi for VB5. MS had about 25 of us in a couple of times to meet with
the PM's and devs. They were sending us hand burned CDRoms with code in the
condition of "you may need to reformat your machine after testing". (yes,
the NDA has expired<g>)

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

They did do a good job on VB6, with regard to language stability and moving
code forward.

Soo.... I do know I was meeting with the people that *should* have been able
to speak for the future of VB. 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.

>> Huh? Out of about 4 megs of source code, I don't know if I have *any*
>> line continuation characters.
>
> With your attitude, you should be using C, man. <g>

Nope, if I go that direction it's always MASM<g>

>> Nope. New language, and they even reused keywords. One "poster child"
>> shows the calousness of this, even if it is easy to fix with "search and
>> replace". They changed the "Wend" to "End While". Why? "Because we
>> thought that's what it should be". So... maybe "End For" and a few
>> others are on the horizon. They're not done yet.
>
> I prefer End While to Wend. I also prefer all the other changes made in
> VB.Net. But I can see how people are resisting having to rewrite existing
> code.

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?

Likewise, some folks would prefer "End For" to "Next"

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.

The point of the matter is that Language Stability is a feature of a
language. MS Basic used to have that feature, it no longer does. Delphi
still does. Borland should paste this in large letters on the front of the
box.

> > The
>> issue is what MS has done to code assets of developers (rather
>> "application owners"). You simply cannot convert apps of any size or
>> complexity without a complete rewrite. That is, quite simply, nuts for
>> something that is supposed to be the "same language".
>
> I think Microsoft has made it pretty darn clear that they are not
> committed to code support from generation to generation of their products,
> since they've failed to provide it (or even a converter that mostly works)
> over and over and over and over again.

It's actually worked well most of the time. That one incident at VB4 (where
they said they "wouldn't do it again") was a clear exception. Moving Basic
code from CP/M to 16bit was trivial. In the move to Windows I expected a
lot of rewrite, but that actually went with almost no changes. With a huge
code base I wrote a simple converter that commented/uncommented procedure
declarations that were needed in DOS (but not in VB). I could modify code
in either environment and use it in the other, hands off.

> Any Delphi programmer who bids on projects has heard over and over again
> from prospective clients that Borland can't be trusted to "be here" in
> five years, and therefore VB was the safe bet.

I've watched the organization from the TP days. It's a low maintenance
organization. It seems clear to me that of the owner wants to get rid of
it, the insiders could buy the rights and get rich. That kind of product
isn't going to "disappear".

> But it wasn't.
>
> So I must admit taking a certain amount of righteous satisfaction in
> seeing the VB champions - who claimed VB was the "safe" choice - get
> burned.

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.

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

> Borland goes to great lengths to provide backwards compatibility - and the
> VCL.net is the latest example.

Great show. I've been watching with interest for a long time. OTOH, VCL is
a library. I'm certainly GLAD it's compatible, but my main focus is on the
core language itself which is also stable.

For the record, it's "forward compatibility", not "backwards". From *our*
perspective as users, we want our code assets to be forward compatible.

> On the other hand, the post-RAD development approach is that:
>
> 1 all code is disposable,
>
> 2 an investment in getting past competent in a language is a bad (too
> risky) investment
>
> 3 problem-domain knowledge good, technical knowledge bad.
>
> 4 don't ever invest programmer time to extend a language past the things
> it does out of the box
>
> 5 hardware beats software as a source of performance
>
> These all go against the oldtime programming code of excellence. Like #5:
> some programmers hate to waste CPU cycles. But for 1-2 weeks of a
> programmer's salary I can upgrade the CPU and make everything run faster,
> not just the optimized code.

"post-RAD" WTF is that! Serious, long lived, applications must be built on
code libraries that can be reused. Reuse of existing code is the most rapid
development tool built yet.

> Obviously, there are lots of exceptions and places where these rules don't
> apply. But to me they are exceptions - places to focus resources in a
> laser-like fashion - while still doing 95% of business the post-RAD way.

Sorry, but I don't know many (any) successful shops doing that. At least
none that are successful for more than a year or two with an app.

>> Now, even if I moved my app to VB.Net where would I be? How long before
>> they broke it *again* (again). The core issue is not complexity or
>> capability, it's trust.
>
> Don't move apps until the old one won't run on the new operating system.

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.

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


> What helped Windows was Microsoft's dominance of the market, and the
> cheapness of the adequate development tools.

MS wasn't all that dominant in the market at the time (I don't know where
you were during all this).

> VB is like the jack that comes with your car - it's free but I don't see
> an garage mechanics using them.

VB was the tool that put the cars on the road. Most cars don't spend much
time in the shop.

>> You're actually wrong about this. They were counting on a large number
>> of VB6 apps being converted to dotnet. They spent a lot of effort trying
>> to get the conversion wizard going, and lobbying developers to move.
>
> An effort yes but if they cared, they would have made it backwards
> compatible. I think we're agreeing here actually.

They really did try hard. They just didn't have a clue what they were
doing. They took it personally when they failed:

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

You may want to look at other quotes here:
http://vb.mvps.org/vfred/Trust.asp


> Nice chatting with you... Good luck in lobbying for VB.net compatibility.
> You never know, every once in a while the customers win one...

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

Dan


.

Relevant Pages

  • Re: Over 100 Microsoft MVPs Have Signed Online Petition - Give Us Back VB!!
    ... My prime interest is *language* stability. ... "VB data controls" are com controls, ... > I wouldn't ever want to use them in Delphi - or in VB; ... My code is core to the app, business logic that is focused on the market I ...
    (borland.public.delphi.non-technical)
  • Re: Advice Needed...
    ... potentially make a top app and really revolutionise internal apps. ... and break compatibility with all former applications, ... they've done with the language, but they seriously needed to provide SOME ... Yes, it would be EXTREMELY popular, I'd imagine. ...
    (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: 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: shift appl. VB6 --> .NET
    ... It is often quicker to build the new app than fix the migrated FUD. ... choose C# as your language (or at least a language other ... detrimental effects of having developers continue to attept to write in a VB6 ... > programming (z.B. ...
    (microsoft.public.dotnet.general)