Re: Over 100 Microsoft MVPs Have Signed Online Petition - Give Us Back VB!!
- From: "Dan Barclay" <Dan@xxxxxxxx>
- Date: Wed, 30 Mar 2005 10:54:06 -0600
"Richard Grossman" <rgrossmanDELETE-THIS-PART@xxxxxxxxxxx> wrote in message
news:424a43af$1@xxxxxxxxxxxxxxxxxxxxxxxxx
> Dan Barclay wrote:
>> "Richard Grossman" <rgrossmanDELETE-THIS-PART@xxxxxxxxxxx> wrote in
>> message
>
>>>I think it's pretty horrid.
>
>> Too bad you didn't learn how to use it properly.
>
> That must be it.
>
>> The only real problem with VB is Microsoft.
>
> When you get over on the business side of things, you see that Microsoft's
> products are dirt cheap compared to the cost of the processes they
> support, and that they are mostly in sync with business requirements.
Microsoft tools are not cheap for lack of spending on them. In fact, MS
spends a TON of money on development tools.
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.
> For the most demanding programmers, their tools are often not
> satisfactory, which is just like saying that for racing at Indianopolis, a
> Ford Escort is not the right car. It doesn't mean the Ford sucks for
> everyone, but it sure does for a race-car driver.
I've looked at a lot of tools, particularly in the last 4 years. MS tools
don't lack for quality. They lack for mission, at least so far as I'm
concerned.
>> The data model is a library external to the language, not that it matters
>> to many of us.
>
> Except those who have to switch grids because the frickin' data model
> changed. What was *that* about?
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.
>> Contrary to popular belief, real apps in VB are not so much data front
>> ends as MS portrayed them for so long.
>
> Aha. So then it's the fault of those who try to access *data* that VB
> seems horrid. In other words, you're saying, just don't use VB as a
> front-end for data and you're A-OK.
Nope, I'm not saying that. I'm saying that *I* don't use it that way
because my app isn't a database driven app. Likewise most of the serious
apps I know aren't thin data covers. I simply don't know if VB is good for
that or not, it could be.
I think MS was pushing this "data frontend" usage to get into big
companies... again on a mission to sell Office and Windows. Dunno how those
worked out, but most "real apps" are in smaller, ISV shops.
> Already, I'm in agreement <g>.
Scary, huh? <g>
>> I seldom "do" data, and when I do I wrap all that in my own functions.
>
> That's the only thing I do. Reminds me of the last programming argument I
> had - about 3 years ago - in the middle of it I realized the other guy was
> a graphics programmer - he was typically given 3 weeks to polish a page of
> code. If I get 3 weeks to polish an entire module, it's a miracle of
> generosity.
>
> 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.
>>>Actually, I think VB is the "dbase" of the 90's: a lot of people who
>>>aren't programmers start messing with it and eventually wind up doing a
>>>lot of programming in it, and some eventually graduate and become
>>>programmers.
>>
>>
>> Think whatever you want. We provide solutions. My degree is in
>> Lectricul Inguneering. I learned FORTRAN in the '70's. You can write
>> FORTRAN code in any language, including Delphi.
>>
>> If it bothers you that I don't have a CS degree... too damned bad<g>.
>> Want to compare toys?
>
> Sorry - that wasn't supposed to come across as a put-down. Although I
> studied a little in school (FORTRAN like you), career-wise it started with
> dBase. dBase made it possible to quickly whip out saleable programs on
> timeframes and at costs unheard of at the time. Ninety percent of the
> dBase/FoxPro community came from previous non-programmer careers,
> including myself.
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>.
> But I hear CS is good for people who want to write compilers, or ROM-code
> for microwave ovens. <g>
LOL. Yea. I've run across some good app devs with CS degrees as well.
They only get good when they get realistic<g>.
>> Yup, dead end courtesy of MS. We should have learned the last time.
>> After the VB4 fiasco they had a handful of us to Redmond and promised us
>> it wouldn't happen again. They actually convinced me that they "got it".
>> The thing is, those guys are long gone.
>
> No, the truth is they never got it - they just convinced you that they
> had. I knew some people their in the 90's and it seemd as though they
> would do and say anything to hit their targets.
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).
There is no standard for VB, nor is there a "keeper of the keys" anymore
(though there used to be).
>>>In VB, there's no there there (apologies to Gertrude Stein).
>>
>> Too bad you didn't find it. It's there.
>
> What's not there are databased components that actually work (the ones in
> Delphi work and the ones in VB are so bad that they are never used),
> reliable distribution packaging, and DLL-management to avoid DLL-hell.
>
> In VB, coming from Delphi, there are exactly 4 things in VB that I like:
>
> 1-Demand for VB programming
> 2-Supply of VB programmers
These don't really matter to a small vertical shop.
> 3-Automatic re-casing of variablesas as you type to match the declaration
Yup, nice. It used to drive me nuts, until they tied the recasing to the
declaration. In earlier versions, if you typed it in a new case it would
change 'em all! That's hell on a version control system, and makes tracking
changes a bear.
> 4-Stop/edit/continue
Yup, really nice. Sadly, the VB folks think putting that back in VB.Net is
going to solve the problem. Remember what I said above about "solving the
*right* problem"?? <idiots>
>> If you're working on simple things, flow doesn't matter<g>. (Sorry, I
>> couldn't resist)
>
> We were just talking at work today and asking who's a binge programmer. I
> had to admit I'm one. When the force is with me, I won't stop until it's
> "done", which could be 3, 4, or 5 AM.
A sign of success IMHO<g>.
>> So, you've just coded a complex fragment, you want to test it and modify
>> if necessary. You "run" then stop to declare vars, remembering their
>> types etc. Now you "run" again... hmmm... what was I doing there? In
>> Basic you would have decorated the vars with their type characters and
>> never skipped a beat.
>>
>> Six of one...
>
> Welllll, you know, even in dotNet, where you can declare vars inline
> whenever you want to, I declare them all at the top. It seems "just plain
> wrong" to me to declare vars all over the place.
See my reply to "eshipman" on this. We don't disagree as much as you think.
<snip>
>> Man, you have a very low threshold of pain. Perhaps it's like having to
>> use ":=" when you mean "="? Or, like having to type the damned ";" when
>> it's clearly the end of the statement?
>
> Objectively now, you type a lot more line-continuations in VB than you
> type line terminators in Delphi or C.
Huh? Out of about 4 megs of source code, I don't know if I have *any* line
continuation characters.
> It's just not efficient to make the default termination and require a
> special character to continue.
Opinion noted. Disagree, but that's opinion.
> And semicolon (;) is way easier to touch-type than an underscore (_).
Yup, but only relevant if you use both. I've used neither!
>>> Add in the mystery of distributing the right components for a VB app
>>> versus the single EXE of a Delphi program, and well...
>>
>> Now *there* is a HUGE advantage of Delphi. Not of the language, but of
>> the development environment. VB folks consider this a big deal.
>
> I really like creating an EXE in Delphi and putting it out on the network
> with no install package required.
Looking forward to it myself.
<snip>
>> Since I had customers who hadn't moved to Windows for some time, I had to
>> maintain two different products.
>
> I had one client who had some OS/2 up until early 1999. I couldn't move
> my app to Windows until that last system went away.
It was nice to be able to maintain one set of common code. I (fortunately)
didn't have any OS/2 clients, though one of the Basic products would emit
OS/2 compatible code (PDS).
>> Again, this isn't about .Net. It's about the Basic language. VB.Net
>> *isn't* MS Basic.
>
> To me, VB.Net is just BASIC with a new set of libraries to learn. No
> biggie.
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 take any programmer who's good in VB6 and give them 3 weeks to pick up
> VB.net. Over that 3 weeks, their productivity is at 50%, and then back to
> normal, and then better.
It's not that people can't learn VB.Net. Again, that's not an issue. 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 don't know if you're aware, but in the initial public beta they still had
a completely different logical expression evaluator. You literally could
take a logical expression out of VB6 and have it throw a different result
(no errors) in VB.Net. Not, of course, that anyone would use logical
expressions in their apps<g>.
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.
> Learning to write OO code is another matter...
Everything has its place. It's not all *that* hard, but this "everything is
an object" bs is just that. There are zealots everywhere, and they
generally accomplish little.
>>>Microsoft doesn't need these people. There are lots more where they came
>>>from. Just like how they came in when a previous grouop of people with a
>>>previous skill set were swept aside.
>
>> MS is fairly well concerned about this loss. There is a huge political
>> mess on the inside because of it, and there are people who's job it is to
>> bring us in. Unfortunately for them and for us, this problem has risen
>> to the point that it will take Ballmer "cleaning house" to fix it, and
>> that's just not going to happen.
>
> Here's another possible interpretation to consider:
>
> There's no huge political mess and MS is not concerned a whit about
> old-school VB'ers. Realistically, where are they going to go? Delphi?
> Sure they should, and I'd like it if they would, but companies are not
> going to shift out to Delphi in numbers significant to Microsoft. The
> ones that don't want Microsoft tools are using Java. The rest will go to
> dot-Net next year, or the next year, or the next.
Could be, but I don't think so. MS itself is already lowering expectations
on dotnet. I don't drive the market, nor do I care about where it goes. My
objective is to deliver my apps on a platform that my user base is
comfortable with. Whatever that is.
> And if they do go to Delphi, so what? Delphi is a licensee of Microsoft
> technology - it just takes a support headache off Microsoft's hands and
> puts in Borlands, and Microsoft still gets paid.
Yup, particularly for dotnet apps. Hopefully Borland is smart enough to
continue development on native environments as well, driven by their
customer base (as opposed to being driven by a need to satisfy some MS
need).
> Microsoft is a business and the tech community just can't over the fact
> that Microsoft acts in their own self-interest and not for the general
> benefit of the programmers of the world.
Agreed.
> The online petition won't cost Microsoft a dime in revenue - almost none
> of those people make the buying decisions anyway.
You'd be surprised at some of the comments we've got, even from nervous C#
devs. This issue of being able to trust them with your code assets is a
real issue.
>> DotNet, as cool as it is, simply hasn't had the uptake that it should
>> have.
>
> Next time you're at your dentist, look over the desk at what they're using
> on their computers. Often it's a *Clipper* program running under DOS -
> they're entrenched.
Yup. Same for a lot of POS stuff. It's a lot faster<g>.
> Hasn't hurt the sales of Windows.
No, those haven't hurt Windows. What *helped* Windows was the critical mass
of apps that launched very quickly. Vertical apps from ISV's and internal
development got Windows on a *lot* of desktops that would have been a long
time coming. VB was at the forefront of that... C apps were just taking way
too long to get on the ground.
> Microsoft usually doesn't attack the users of the previous generation of
> any of it's products - it attacks the users of the generation before
> that - just look at the poor souls still trying to run NT.
<g>Marketeering through creative obsolescence.
>> One of the key reasons for that is the inability for successful
>> developers, with successful apps on the ground, to bring them to DotNet.
>
> They don't care. And those apps can stay in VB6, which Microsoft is
> spending 0 on.
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.
>> When Windows was getting off the ground it struggled for some time, until
>> VB allowed existing apps to be brought forward to create a "critical
>> mass" in the market, and this has not happened with DotNet. Essentially
>> everything developed in DotNet has been from scratch, and that has been a
>> huge handicap in getting the mass up.
>
> I programmed in dBase and then FoxPro until after Microsoft bought them
> and beyond. Then Microsoft came out with the first version of Fox that
> wouldn't compile previous applications *ever*. Up until then, I could
> compile my old dBAse III apps if I wanted to.
>
> So I did a zero-based analysis and decided that if I had to learn
> something from scratch, I'd learn Delphi.
Good move. Did you know that Foxpro apps actually do move to dotnet?
Interesting they did that with Fox, but not with VB. That wasn't a
strategic decision... they *thought* they were moving VB apps as well. They
were quite surprised that it didn't work. FWIW, a reasonable number of the
VB management team have a Fox background and no VB background (free clue?).
> Delphi is and will be among the top choices with people for whom IDE,
> language quality, development process, and application deliverability is
> of high importance.
I don't doubt it.
> But there are many other considerations than those from a business
> perspective.
>
>> Well, actually a 'VB to Delphi' newsgroup has been suggested <g>.
>
> Or "borland.public.delphi.VB-Coder-Welcome-Center".
Good title, if a little verbose<g>
Dan
.
- Follow-Ups:
- Prev by Date: Re: Skype - 160,000 new users per day
- Next by Date: Re: VB6 Users Considering Legal Action?
- Previous by thread: Re: VB6 Users Considering Legal Action?
- Next by thread: Re: Over 100 Microsoft MVPs Have Signed Online Petition - Give Us Back VB!!
- Index(es):
Relevant Pages
|
