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

From: Dan Barclay (Dan_at_MVPs.org)
Date: 03/13/05


Date: Sat, 12 Mar 2005 22:13:25 -0600


"David Farrell-Garcia" <DavidFarrellGarcia@nospam.nospam> wrote in message
news:42331a40@newsgroups.borland.com...
> Dan Barclay wrote:
>
>> A lot of people who don't understand VB apps very well think this,
>> but it's not right. Most serious VB apps, by necessity, use a fair
>> number of 3rd party components. Almost all the 3rd parties have
>> folded their tents. I'm already seeing pleas for help when these
>> things break apps (usually caused by classic dll hell).
>
> We used the early version of VB (1, 2 & 3) for some projects years ago,
> as well as VB for Dos so I am out of the loop but not completely
> ignorant about VB. I do know that there were more VB 3rd party vendors
> then Delphi could ever have dreamed of. While they may not get fresh
> updates I see no problems using the same 3rd party components they used
> for VB 6. There were literally tons of them.

Yes, there were tons of them. Few are left supporting their components and
you'll have to look at the overall situation to understand how unlikely it
is that any will be left before long.

> You also should
> understand that Delphi 3rd party components have also all but dried up.
> Yes, there are a few majors that are for now still producing libraries
> but nothing like it used to be and many, if not most Delphi programmers
> roll their own these days. I assume VB developers could do the same?

So far we haven't had trouble locating what we need in Delphi, and with
source in Delphi for the most part. They can be linked into the project as
opposed to VB controls which cannot.

VB 3rd party controls were almost exclusively in C++ and the controls also
had a lot of dependencies. Trying to paw through those is a crapshoot.

>> We have been bit by this before and have source for the few
>> components for which it was available. For the rest, we get a "plan
>> B" (usually an alternate component) before we proceed. Not many
>> shops are as anal about that as we are, and we wouldn't be except for
>
> The bigger difference I suppose, as you mention was the lack of source
> code provided by VB 3rd party vendors. That was a tragedy and from day
> one most Delphi developers would not consider 3rd party components
> without source code. I am not sure why VB'ers did not make similar
> demands way back.

Yes, in the DOS days you could get source. In fact, *every* library I
purchased came with source. That was mostly MASM, but it was all easy to
manage.

>> I don't claim to know a lot about maintaining Delphi apps, but I do
>> see an obvious difference. In most of my research, and the little
>> work we've done, we've been able to get source for components (in
>> Delphi) and the components are linked.
>
> Not sure what you mean by the "components are linked". Yes, they can
> be linked as a .dll (.bpl in Delphi) or compiled into the application
> but I am not sure what point you are making here.

I'm talking about static linking as opposed to dynamic linking. Can't do
that with VB.

>> That is only true if you believe VB.net is a good place to end up.
>
> which is why I included this to the statement: "that is, if they want
> to go .Net at all".

I'm still not being clear. I'd like the *capability* of deploying my app in
.Net. So, you could say that I "want to go to .Net". I do NOT want to go
to VB.Net. It has NOTHING to do with .Net.

So, forget about .Net or not .Net. It's about VFred and VB. I don't want
anything to do with VFred. I'll use C# before I go there. That's not
because of the language per se, it's because if I go there I know I'll have
to rewrite again before long. Trust me, they are *not* through cleaning up
the language.

>> This isn't the first time MS has changed fundamental definitions in
>> VB, and it won't be the last. I've seen discussion by the folks
>> inside MS who are charged with maintaining the language, and these
>> guys do not think that making language changes from one version
>> change is a problem. They have stated exactly that. I'd go to C#
>> before I went to VB.Net.
>
> That is fundamentally a fact but I don't see any guarantees for any
> developers. Just take a look at this group and you will see lots of
> fear mungers worried that Borland is going to drop Win32 development.
> And in fact they will, if the market moves them in another direction.
> The difference between Borland and Microsoft is that Borland will do
> it only when the market dictates while Microsoft dictates the market.

The key issue is whether, when they drop Win32 development (which they will
at some point), there is a way to move forward. As it turns out, there
already is for Delphi. There is not a way to move forward for VB.

>> Those who move forward with VB.Net can look forward to another
>> significant change in the language in the next 3 to 5 years,
>> requiring another complete rewrite.
>
> In this industry, 5 years is a very long time. As Rad tools build yet
> more abstraction layers on top of the native API all developers who
> rely on these tools face a level of uncertainty about the future. The
> closer you are to the bone the better your chance of enjoying language
> longevity. Modern day development is a roller coaster ride full of
> uncertainty. Successful shops will ride the ride, keeping versed on
> new technologies, but only investing in them when it makes sense (for
> their particular shop) to do so and not just for the sake of the
> technology. The most counter-productive thing to do is to fight it.

For technology improvements and platform changes, a lot happens in 5 years.
That's one reason why app code libs should be written in a way that isolates
platform and i/o code from business rules.

For a serious vertical application, 4 or 5 years is not a long time.

Design, development 2 years
Market development 2 years
Start reasonable sales
SPLAT

That is not the case for thin web apps. The web apps I've seen are
basically front ends for databases and don't require much of a code library.

Most of the VB shops I'm familiar with actually don't do much of that. Most
are developing business solutions, used as mission critical apps, for small,
medium, and large businesses. Quite a number have some sort of database
underneath, but *all* of them are based on a rich set of business rules
(read: significant code libraries). Most of those apps are heavily client
based, and likely will remain that way because of their mission.

One fairly recent survey indicates nearly half of VB projects are single
dev. Another 35% or so are 2-3 devs. That is, 80% of projects are 3 devs
or fewer. Those guys are as deep in business knowledge as they are in
programming knowledge, and that matters. It affects the above timing, and
it also means that it's difficult to replace the devs with "just
programmers". I'd be willing to bet that Delphi apps fit this profile as
well.

> I suppose you are here to see what Borland my have to offer. All the
> complaining on this forum aside, it is indisputable that Borland has
> consistently tried to provide the broadest capabilities for developers.

I'm not completely new here. The complaining seems fairly shallow based on
where I've been <g>.

> While not all of these have enjoyed the same level of success they
> should be given huge credit for trying to fill the needs of all
> developers. They gave us cross platform development tools while still
> committing to .Net.

Yup. I wish MS had done the same with VB. It's not going to happen, of
course.

> We, as Delphi developers do have choices, at least
> for now, but products will be dropped or left stagnant if the market is
> not there, as well they should, so there will always be the
> disgruntled. No way to change that.

Again, folks need to realize that this is *not* what VB developers are
complaining about. Had they left VB6 to rot, but had provided a way to move
to .Net, there would be little complaining. We've had platform changes
before. I came from CP/M for crying out loud. CP/M (and TRSDOS) -> DOS ->
Win16 -> Win32 ... all those have been relatively clean for Basic users.
They have replaced the team inside MS.

> Also because of the wide product
> ranges, and limited resources, Borland may take longer to tweak new
> releases to near perfection and that always generates heat but they
> have always survived despite the nay-sayers. So add that to the mix
> while you are considering your future development plans.

I've been watching Borland for a long time. You are preaching to the choir.

> In my opinion, VB folks need to come to the reality that they are going
> to have to develop new/different skills or eventually be left out of
> the market. Rather then a futile attempt to move the un-movable they
> should use that energy to retrain on whatever technology they think
> will have the longest legs but without sacrificing existing projects
> which they can and should maintain in their current version of VB.
> Anyway, that is my opinion for what it is worth.

Your view is valid, but only for those who don't have deep libraries. I
can't think of another language that has changed core language syntax in
this manner. We're talking about core syntax and data type definitions.
Unless you have been there (and if you don't have large VB6 libs, you
haven't), you will have a difficult time understanding it.

You're talking about the normal progression of a language through different
products and platforms. I'm talking about changing the core langauge
itself.

Dan



Relevant Pages

  • Re: first impression and uneasy feeling... (long)
    ... IDE is very familiar to Delphi users ... Easier deployment of apps ... I think a very large percentage of developers using Delphi to do GUI ... > good and several bugs are still in this release. ...
    (borland.public.delphi.non-technical)
  • Re: A VB6 fan asks... why do YOU stick with VB6???
    ... and developers. ... I also agree that they can do far more with Delphi to ... used years ago as a teaching language and they let that go completely. ... simply because things "fit" better into the whole. ...
    (microsoft.public.vb.general.discussion)
  • Re: Lets think who will like to say delphi is dying?
    ... All important Software ist still native and will be native in the future, there is a market for delphi, they only need to pick it up. ... are using to write Desktop apps. ... I have tried every thing I could get my hands on for windows and none come as close to Delphi in terms of productivity and ease of use. ... At corporate level everywhere only those tools are utilized which have got a large following of developers and thus it is easy to find developers for that tools. ...
    (borland.public.delphi.non-technical)
  • Re: Lets think who will like to say delphi is dying?
    ... All important Software ist still native and will be native in the future, there is a market for delphi, they only need to pick it up. ... using to write Desktop apps. ... I have tried every thing I could get my hands on for windows and none come as close to Delphi in terms of productivity and ease of use. ... At corporate level everywhere only those tools are utilized which have got a large following of developers and thus it is easy to find developers for that tools. ...
    (borland.public.delphi.non-technical)
  • Re: Lets think who will like to say delphi is dying?
    ... All important Software ist still native and will be native in the future, there is a market for delphi, they only need to pick it up. ... using to write Desktop apps. ... I have tried every thing I could get my hands on for windows and none come as close to Delphi in terms of productivity and ease of use. ... At corporate level everywhere only those tools are utilized which have got a large following of developers and thus it is easy to find developers for that tools. ...
    (borland.public.delphi.non-technical)