04131408.txt 13-Apr-00
Life Imitates Art
Or VB imitates VO.
Micro$haft have announced that the next version of VB will
(finally) include full OOP technology.
Inheritance, encapsulation, ploymorphism, overloading, free
threading, and structured error handling are just some of
the features that have been mentioned.
Now VBers can learn about some of what we've been doing for
years. :)
http://msdn.microsoft.com/vstudio/nextgen/
Has the details. Enjoy
--
g.
Gary Stark
gstark@RedbacksWeb.com
http://RedbacksWeb.com
I've worked at a couple of companies that use VB and
honestly, I have never seen a nice VB app. On the other
hand, I've seen some very impressive VO and Delphi apps.
Of the VB apps that I've looked at, performance has been
very slow and the apps don't look and feel at all
professional. I would imagine that this is not the case
with apps developed by expert VB programmers. Since you
develop using both products, can you tell me if in VB one
can develop professional looking/performing software?
Please pardon my ignorance Gary. I would appreciate your
comments.
Fernie
Fernie,
I can answer that one for Gary. I use VB regularly for
Clients (since many of mine are corporates...etc and I have
little choice on the tool).
IAC, Yes, its feasible to create a professional, robust,
stable and fast VB app. However, it requires the following:
- Proper time devoted to analysis and design. Gee, this may
seem like a no-brainer, but the problem with the VB
marketing is that all the "dabblers" think that the wizards
will create all of this for you automatically. WRONG
- Proper time devotes to class designs. VB doesn't have real
inheritance, which requires some massaging of "ideal"
designs to cope. Most often you have a lot of related
classes, which contain a LOT of duplicated or redundant code
to get the desired behaviour. It works well, but takes time
to debug as a result.
- Error handling. This is the one are that VB is, without a
doubt, piss-poor on. Error code has to be placed EVERYWHERE
if you want an app to be even partially stable. Strict
adherance to design and coding standards is essential here.
Gee, no wonder that it isn't done.
- Speed. Actually, VB 6.0 isn't too bad. Yes, It won't beat
VO or VC++ in a shoot out, but it ain't bad for even large
db apps. The problem is that the standard wizards...etc for
VB data access don't scale well, and you have to know a lot
about the database concerned, plan and design all acess
carefully, and do a lot of load testing to ensure there are
no bottlenecks.
This is especially interesting with Access/JET. the fastest
way to code a JET system (using MDB files) is to code in the
old Clipper 3GL fashion (eg: SEEK everything). This is
TOTALLY against all the rules documented for both VB and
Access, but its true - you get 5 fold speed increases!
- Server databases aren't so much an isues here, except to
say that the (in)experience of the average VB programmer can
cause problems, as they expect wizards to solve everything.
- Its interesting how the VB journals come back to the topic
of "algorithms" regularly, as though its a new concept. They
highlight a problem - people for whom VB is their first and
only language generally don't have skills in "coding their
way out of a hole", to use a favourite expression of mine.
But then, my opinion is that you are a better
analyst/designer/programmer if you have worked on several
environments - as you can solve problems by drawing on a
wider range of experiences.
- ActiveX and DLL Hell. Because MS insists on hooking
everything in VB to ActiveX (all its own classes are
actually ActiveX internally), distribution is problemmatic.
To be fair, this isn't so much VB's problem, as MS's when
they continually issue updates to key subsystems inside
things like Ofice and IE (which then break previously
working code elsewhere!).
I think you can see the theme of my diatribe here . Those
who know me will recognise this rant, and I go off on it
regularly .
In summary, VB makes it extraordinarily easy to make a BAD
program really quickly. This is its primary weakness - and
the weakness of all the marketing strategies, which
encourage programmers to build huge things without any
methodology.
This is a constant no matter what programming langauge is
being used. Shops that have rigorous analysis/design/coding
methodology, and proper project management (no matter what
project model they use) and deep experience generally
succeed. those that don't have this either create garbage,
or don't create anything at all.
Getting back to the VO:VB question. While The next version
of VB will bring it up to par on a number of technical
points, IMO the most important difference remains the
experience and skill of the developer and the wider project
team. I think VO lends itself to this more, simply because
it doesn't pull any punches - it immediately says you have
to know what you are about if you want to build a VO system.
If you haven't done your analysis/design, then you get into
a hole very quickly, instead of later.
Our community went through this phase change several years
back when Clipper 5.0 first introduced objects. there was a
LOT of fallout over this issue, and the result was that the
clipper community became one of professionals only - the
dabblers couldn't handle the newer concepts (which made
quick and dirty code difficult to use on a large scale) and
left.
The dBase IV product never went anywhere because they
attempted to keep both groups - the dabblers and
professionals, without getting anywhere fast. VB suffers
from the same problem - its made up of a LOT of dabblers and
a small cadre of professionals - and MS is struggling to
satisfy both.
Lastly, since VO is written using itself. That is, the class
library we use to build apps is all VO code. We have an very
internally consistent and extensible environment to program
in (much like the Delphi model). The benefits for systems
design cannot be underestimated here. VB contains so many
"internals" and "don't go here" stuff that coding a generic
system is a joke sometimes, as you are faced with many
inconsistencies, objects you can use one way and not
another,...etc.
seeya...Pete
Peter Fallon
www.castlesoftware.com.au
Hi Peter,
>
- Error handling. This is the one are that VB is, without a
doubt, piss-poor on. Error code has to be placed EVERYWHERE
if you want an app to be even partially stable.
>
Is't like this?
Private Function GetUserID() As String
Dim sUserName As String * 255
Dim lSuccess As Long
Dim lErrNo As Long
Dim sErrSource As String
Dim sErrDesc As String
Dim lLength As Long
On Error GoTo ErrHandler
lLength = Len(sUserName)
lSuccess = GetUserName(sUserName, lLength)
GetUserID = Left(sUserName, lLength)
Exit Function
ErrHandler:
lErrNo = Err.Number
sErrSource = Err.Source
sErrDesc = Err.Description
Err.Raise lErrNo, cModuleName & ".GetWorkStationID>>" &
sErrSource, sErrDesc
End Function
This is equivalent in VO:
METHOD cGetUserName() AS STRING PASCAL CLASS HRSysInfo
LOCAL DIM abBuffer[MAX_COMPUTERNAME_LENGTH + 1] AS BYTE
LOCAL dwSize AS DWORD, cGetUserName AS STRING
dwSize:=MAX_COMPUTERNAME_LENGTH + 1
HRError{}:vAssert(GetUserName(@abBuffer, @dwSize), ;
"GetUserName", {})
// Exact equivalent with VB code above should be:
// GetUserName(@abBuffer, @dwSize)
// But I want to handle the case when GetUserName fail
// in VO
cGetUserName:=Mem2String(@abBuffer, dwSize-1)
RETURN (cGetUserName)
In VO error handler can be customize, in error handler we
just simply log down the information we think which are
useful, and this is a one time job and transparent to other
programmer who use our error handler. Since error are
automatically handle by error handler, we can achieve same
result(even better result) with lesser code compare with VB.
This is why I choose VO for big project, this will save a
lot of time on programming and debugging, less code less
bug! :-)
Regards,
Wong
Wong,
>Is't like this?
thats correct, but not the half of it.
Vb, as you showed, still uses a GOTO to execute error code,
interrupt style. However, what this doesn't show is that
this error routine will be called by any error, even if its
in a nested call somehere - but the error routine will not
know this. There is no way with straight VB to get a call
tree, or to resume at the exact point of error in a nested
routine.
VB has no application wide error handler - which is why you
have to put error code everywhere (and I Mean everywhere!!).
There is no concept of "ownership", whereby an error in an
event will be passed to the containing window...etc.
To cope with the above, I have a standard block of error
logging and handling code (about 20 lines) that goes in most
events, functions and routines. In a large system of several
dozen objects, each with a dozen or so eents, methods...etc,
several dozen forms with dozens of event each - you do the
math on the amount of redundant code that makes for...All
absolutely essential for a robust system, one that picks up
after itself, and logs every problem in full to you can
trace the error later.
Only the error handlers in Delphi are on par with those in
VO. Its one of the BIG black marks again MS for allowing
such a poor state of technology to remain in something as
"mature" as VB. I once asked an MS bloke whether this would
be fixed (back before VB 5 was released), and he indicated
that in MS's view, if you wanted to code professionally, you
should be using VC++. Obviously with the announcement Gary
highlighted, this point of view has changed, but its only
taken them how many years??
seeya...Pete
Peter Fallon
www.castlesoftware.com.au
Hi Peter,
I'm not familiar with VB, and I'm also not good at designing
compiler and programming language architechture, but in my
impression of the existing VB language architecture, it
can't support full OOP feature seamlessly, in other word,
the new OOP support will not backward compatible with
existing VB code, do you think so?
Regards,
Wong
Wong,
No, the reason VB couldn't support inheritance till now is
that ALL VB objects, internals, the one you write
yourself...etc are all COM objects. That is, the windows
ActiveX/OLE engine is behind all instantiation, control,
method passing...etc. The whole schebang. The VB language is
limited by the COM engine only. As you know, COM didn't
support inheritance till COM+ in Win2K.
In fact, when you examine all of the new object features
advertised for the next version of VB, they are simply the
VB versions of all the new features in COM+. Nothing more,
nothing less.
Its this linkage which leads me to suspect that VB may be
more tightly bound to Win2K than I'd like. I hope MS allows
us to use these new features on Win9x and NT 4.0, otherwise
they'll be useless.
MS writes a LOT about the whys and wherefores of the feature
selection in prior versions of VB - and its a real laugh,
for anyone who has used say VO, Delphi or C++ - since the
reason given for the limits of VB are nothing but rubbish -
apart from the obvious assertion that COM is slow.
Back in VB 4.0, MS made the choice to bind the product
tightly to their COM engine. This means its piss easy in VB
to make COM objects like controls, ActiveX servers...etc.
But of course its limited to only those things COM supports
- and so the language wasn't as rich as it should have been.
On the reverse side - its also why using COM is a bitch for
other language products, as you have to denigrate the
richness of the language you have in order to satisfy COM
requirements!
seeya...Pete
Peter Fallon
www.castlesoftware.com.au
Hi Peter,
Before Chinese New Year, a software vendor invited me to
joint their banking software project, but for marketing
reason they choose VB as their development tool. Thanks for
your information, now I'm firmed, if they not going to
change their tool, I will not going to joint them.
Somehow money are not the most important thing to me, I'm
more toward to come out the product I will proud of.
As long as company still can making money!
Thanks,
Wong
>
No, the reason VB couldn't support inheritance till now is
that ALL VB objects, internals, the one you write
yourself...etc are all COM objects.
>
So there must be pretty huge overhead code, right?
Pavel
Pavel,
>So there must be pretty huge overhead code, right?
Not so much overheads, although the VB runtime is now 1.8M+
(that befreo you add data manipulation dependencies). More
that its extremely sensitive to the OLE environment and
general OCX/DLL environment on a destination PC. I've had
obsure problems with installs that were only fixed when the
PC was wiped, and windows (95 or 98) reinstalled from
scratch. Despite having carefully checked the version
numbers of the declared dependencies.
You don't notice this overhead during runtime - VB 6 is
fairly fast. You notice it in little code things, like
realising that the OLE engine, when faced with:
Object1.object2.property
Will actually create an instance of "object2" just to
execute the property (where you'd think the instance should
already be around to use...). Place this inside a loop, and
you have an interesting and non-intuitive optimisation
problem.
Other things like having to .close all JET objects before
SETting them to NOTHING. Something you MUSt do to all
objects otherwise the garbage collector doesn't tidy up the
object's memory properly, internal OLE counters go
astray...etc. If you don't .close it first, then the object
is cleaned correctly, but all the data elements it may point
to indirectly remain. the potential for subtle memory
fragmentation is extreme unless you are *very* rigorous with
your code.
The above is probably why some odd problems happen with VO
and ActiveX, as this is a fundamental problem to COM, not VB
as such.
Basically it comes back to my original point. You CAN do
good things with VB, but it takes experience, patience, and
a LOT of attention to detail, and your analysis and design.
seeya...Pete
Peter Fallon
www.castlesoftware.com.au
Peter,
>
MS bloke whether this would be fixed (back before VB 5 was
released), and he indicated that in MS's view, if you wanted
to code professionally, you should be using VC++.
>
This reminds me about a UG meeting we had last year. We
invited a tech guy from MS to show us NT 5, as it was called
then. He also showed us VB and VC++ working together. After
the meeting I and a few other guys had a talk with this MS
guy and asked him about his own oppinion about MS dev tools.
His personal oppinion was that you write the user interface
with VB because that's easier than with VC++, but you write
the business logic in VC++ as VB is just not good enaugh for
that.
That's the MS guy comments. I cant comment on that as don't
use VB or VC++
--
Regards,
Lars-Eric
http://www.clippersweden.se
Lars,
>
This reminds me about a UG meeting we had last year. We
invited a tech guy from MS to show us NT 5, as it was called
then. He also showed us VB and VC++ working together. After
the meeting I and a few other guys had a talk with this MS
guy and asked him about his own oppinion about MS dev tools.
His personal oppinion was that you write the user interface
with VB because that's easier than with VC++, but you write
the business logic in VC++ as VBis just not good enaugh for
that.
>
its also their way of escaping any critisisms of the VB
object model (lack of inheritance...etc) - by saying that
you should use C++.
Evidently MS has tried on a number of occasions to write
some of their own (commercial) software in VB, and failed
miserably (and then turned to C++).
seeya...Pete
Peter Fallon
www.castlesoftware.com.au
Peter,
I think you're absolutely right about whether MS eats their
own dogfood where VB is concerned. I attended a large MS
conference about a year ago in which several large e-
commerce case studies were presented. One was an internal MS
project and the others were client projects with MS
involvement.
Anyway, every single one of them ended up using C++ for the
business logic even though most of the projects had
originally been "prototyped" in VB. One of the presenters
(not from MS) was very candid and explained that the VB
version just wasn't usable so they had to rewrite.
Ginny
Ginny,
>
I think you're absolutely right about whether MS eats their
own dogfood where VB is concerned. I attended a large MS
conference about a year ago in which several large e-
commerce case studies were presented. One was an internal MS
project and the others were client projects with MS
involvement.
Anyway, every single one of them ended up using C++ for the
business logic even though most of the projects had
originally been "prototyped" in VB. One of the presenters
(not from MS) was very candid and explained that the VB
version just wasn't usable so they had to rewrite.
>
compare that with VO, where the whole class engine is
VO!
Or another example. I attended the first Delphi conference
in San Diego back in 95. There, as part of the demo of the
upcoming "Delphi 2" (the 32 bit version for Win95), they
actually loaded the entire source code for the delphi 1.0
IDE into 2.0 as a project to show its backwards
compatibility (It was ALL written in dephi, except for the
actual Pascal compiler), and hit Compile - and it did!!
(after about 10 minutes, after all it was about 150,000
lines of code...). That was impressive - and showed they
weren't afraid to use their own tool!!
seeya...Pete
Peter Fallon
www.castlesoftware.com.au
(
geocities.com/n_s_wong/vo) (
geocities.com/n_s_wong)