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



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!


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

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.

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.

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.


Coming from radically different experiences, it's easy to see it's natural that we differ in our outlook.

Maybe not as much as you think.

I think we both like a good discussion, and therefore don't mind taking up one side of the debate for the purpose of this thread.


Yup. The key to a strong (valuable) application is *subject matter knowledge*. Strong code is worthless if it doesn't solve a problem. More correctly, solve the *right* problem<g>.

(Well, now you've ruined the great argument we were having...)

Absolutely. Give me the person with the right background, understanding, and ability to research, and the tool is secondary.

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.


Anyhow, in the case of VB, time will tell...

These don't really matter to a small vertical shop.

I did a lot of VB when the dotCom bust hit California. Any port in a storm. I found I could get the job done in VB. It just cost more, took longer, ran slower, was less reliable, and didn't look as good. Other than that, VB was great... <g>


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


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


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.

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. Because I always knew they would.

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

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.

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.

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.

The online petition won't cost Microsoft a dime in revenue - almost none of those people make the buying decisions anyway.

Disposable code.

No, those haven't hurt Windows. What *helped* Windows was the critical mass of apps that launched very quickly.

What helped Windows was Microsoft's dominance of the market, and the cheapness of the adequate development tools. VB is like the jack that comes with your car - it's free but I don't see an garage mechanics using them.


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.


Good move. Did you know that Foxpro apps actually do move to dotnet?

But FoxPro has become such a mess of lash-ons at this point... However, the continuing development is good in supporting the faithful.


>> borland.public.delphi.VB-Coder-Welcome-Center

Good title, if a little verbose<g>

That's me all over <g>.

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




Relevant Pages

  • Re: Visual Basic.net
    ... if the feature is written clean for the application's purpose will not ... but frankly as a programmer what do you want ... expecting to have an object for everything. ... I should mention that i don't mind .Net, but i don't like what it's ...
    (comp.lang.basic.visual.misc)
  • Re: .NET and Delphis future
    ... Big name products are still being built for API. ... Real objects, decent languages, business apps ... The world's best kept secret is that an experienced programmer when writing ... desktop apps gets the most value for $ with Delphi. ...
    (borland.public.delphi.non-technical)
  • Re: Know any good OOA/D book
    ... Nile while the smaller apps are like villages on the Nile's edge. ... I need to be able to read large source code bases, ... architecturally either what went wrong or why, despite a programmer ... Most architectures underwhelm me with their support for specifying ...
    (comp.object)
  • Re: RFC - New Object-Oriented Method of Parallel Programming (Shorter Version)
    ... Now it includes a very short - programmer model only - specification: ... MPI BSP, Bulk SCheduling Processor. ... tags of working apps. ... I got to thinking about the INSTRUCTIONS message above, ...
    (comp.parallel)
  • Re: Odd behaviur...
    ... libraries, most of which are your own, the includes are easily managed. ... >>left wondering why a programmer capable of producing such code would ... Delphi and inserted as dlls into the existing C code base. ... made to new looking apps with Delphi GUI and C dlls carrying the older code. ...
    (comp.lang.pascal.delphi.misc)