🚀 go-pugleaf

In article , balchen@sn.no (Jens Balchen Jr.) wrote:

>mobergru@oslonett.no (Rune Moberg) decided to share with us the
>infinite reservoirs of stupidity:

>>(It seems that even MS use Delphi more than VB, just take a
>>look at ROADMAP.EXE included on a VB4 CD near you...)

>you can say MS used Delphi for Roadmap, but to say they use it
>"more" based on this is ridiculous.

It's not ridiculous.  Just unfounded. :-)

>Jens (balchen@sn.no)

George


===============================================================================
 George R. Torralba              xxxxxxxxxxxx                  Batang Cebu!!!
 Seattle, Washington             206.227.0821              MIME mail accepted
===============================================================================

In article <4fbkh0$8au@news4.digex.net>, ell@access1.digex.net says...
>
>I find Visual Basic to be a nice complement to my C++ tools, as I'm sure
>Delphi and similar are.  Admittedly Delphi can "put the pedal to the
>metal" somewhat more than VB. 
>
>Elliott

I agree with Elliott, Microsoft has really place Visual Basic as a wonderfull 
interface developement language with great qualities of mixed language 
developement features.  VB can integrate with C++ through DLLs, OLE, and OLE 
custom controls.  (leak/rumor) That version 5 will support true compiling to 
machine code not pcode.
Remember that software developement is big task which includes the pain 
stacking customization of the interface ... C++ does not allow for easy and 
fast customizing of interfaces that enviroments like Delpi and VB support.
A misunderstood fact about pcode in VB is that it must be so slow because 
each instruction must be interpretted.  One statement in VB may be the 
equivalent of 100 statements in C++ ... the overhead of interpreting the one 
statement per 100 c++ instructions is pretty minimal for the flexibility and 
simplicity gained by the language.  A VB program is as good as the programmer 
... unload processing onto APIs and controls that are written in C/C++/ASM.

We are putting the finishing touches on a training package that currently has 
full screen full motion video.  The video contains actors that can be touched 
using a touch screen or a mouse - these movie real life actors are tracked 
dynamically to determine who got touched.  The program simulates a party at 
the ambassadors party in paris where you can interact with people in real 
time.  The entire program is based in Visual Basic attached to an Access 2.0 
database using a handful of VBX controls.  you would never think that Visual 
Basic was used to develope the package ... and the time saving was unreal 
compared to full developement in C++.

The software is called Tuning In! developed by Motivational Concepts, Inc. 
used in Tuning In! training sponsored by Chamber of Commerces across the 
nation.

This is not comparison to go to VB over C++, but never underestimate the 
power of a software package...Use the right tool for the right job.  Which in 
many cases is several packages for mixed language developement.

	N. Scott Vann
	Motivational Concepts, Inc.
	Software Engineering/Multimedia Training Systems

Good luck to everyone...

Scott (scottv@cstone.net) wrote:
: equivalent of 100 statements in C++ ... the overhead of interpreting the one 
: statement per 100 c++ instructions is pretty minimal for the flexibility and 
: simplicity gained by the language.  A VB program is as good as the programmer 
: ... unload processing onto APIs and controls that are written in C/C++/ASM.

  Tell that to the end user.  In situations where the end user is paying for
the finished product, as opposed to development time (ie shrinkwrap) Visual
Basic is useless.  Even if you unload the processing onto DLLs, the
interface crawls on a VB application compared to one coded in C/C++.  A
seasoned MFC developer can crank out an interface as fast as any VB coder
can, plus the interface will be quicker and (IMHO) more professional
looking.

hraiser@cloud9.net decided to share with us the infinite reservoirs of
wisdom:

>  Tell that to the end user.  In situations where the end user is paying for
>the finished product, as opposed to development time (ie shrinkwrap) Visual
>Basic is useless.  Even if you unload the processing onto DLLs, the
>interface crawls on a VB application compared to one coded in C/C++.

since both rely on the API, I can't imagine why.

>A seasoned MFC developer can crank out an interface as fast as any VB coder
>can, 

yeah? I can make a button on a form ten times as fast as you can (this
includes the form, of course). it took me 2.9 seconds to have a one-form,
one-button app up and running, from I started moving the mouse 'til the app
had stopped loading. you will have to do it in less than 30 seconds to
prove me wrong. :)

>plus the interface will be quicker and (IMHO) more professional
>looking.

since MS decides what is the de facto standard, I guess not.

Jens (balchen@sn.no)
-- 
Newbiehood is not a period of time, it's a way of life.

http://www.sn.no/~balchen
ftp://ftp.sn.no/user/balchen/

MS did develop VB, however some of the work was developed by Cooper 
Software. (I can't remember which bits, but apparently was quite 
substantial).

MS credits Cooper Software in VB's startup window.

Dave

Jens Balchen Jr. (balchen@sn.no) wrote:
: >Basic is useless.  Even if you unload the processing onto DLLs, the
: >interface crawls on a VB application compared to one coded in C/C++.
:
: since both rely on the API, I can't imagine why.

  Neither can I.  Why don't you experiment?  Create a form with 10 or so
controls on it in Visual Basic and run it.  Watch the form thrash around
while drawing the controls.  Now code up the same interface in C or C++ and
run it.  Much snappier, eh?  

: yeah? I can make a button on a form ten times as fast as you can (this
: includes the form, of course). it took me 2.9 seconds to have a one-form,
: one-button app up and running, from I started moving the mouse 'til the app
: had stopped loading. you will have to do it in less than 30 seconds to
: prove me wrong. :)

  Then that settles it!  I will use Visual Basic for my backlog of one
button functionless forms!  My clients will be overjoyed.

>OTOH, their DOS Basic compilers were fantastic.

_What_ DOS Basic compilers??????. If they had any, why did they give the 
idea up??

Dave

Jack...
I can agree with you up to a point.  I believe it is a fine line.
And I believe that one "crosses the line" when the decisions in the
called routine have to infer a lot of semantic content based on the
parameters, and/or a combination of parameters.
John

jackf@sisna.com wrote:
> 
> On Sun, 18 Feb 1996 17:56:34 +1000, John Osborne
> <josborne@magna.com.au> wrote:
> 
> >Pat, et. al....
> >The compiled .vs. interpreted debate is partially bogus.  Even in
> >compiled languages, on a PC or a mainframe, as soon as ones code enters
> >a runtime library routine, you are -probably- off into
> >interpretation-land.
> >I say -probably- because if your runtime routine has any conditional
> >statements that cause the routine to act differently depending on
> >parameter content (i.e., different logic paths) it is
> >"mini-interpreting".
> >
> >For example, you call the printf routine in -C-, or a formatted -write-
> >statement in Fortran, VB's Format$ routine, or just about any
> >non-trivial Delphi component, and you are executing an interpreter of
> >that language feature.  Sure, the printf function in the -C- runtime
> >library is compiled, as is the ChartFX component in Delphi, or the
> >read/write routines in a Tandem Cobol program, but the runtime system
> >has to -interpret- your parameters via lots of conditional statements to
> >make sense of your parameters/data and perform the requested action.
> >When using VB or other -statement based- interpreted languages, where
> >most people suffer a performance hit is doing things like writing their
> >own INSTR function -within- VB.  Each p-code statement has to be
> >interpreted via VBRUNxxx.DLL which is far worse than just using the
> >library routine.
> >
> >Regards, John
> >
> >viewer wrote:
> >>
> >> Pat White <pat@pwhite.demon.co.uk> wrote:
> >>
> >> >In nearly 40 years in computing I've never come across anything in any
> >> >language definition that prevents compiling. That includes BASIC which
> >> >is where this discussion started and p-code. Likewise, they COULD all be
> >> >interpreted, only most companies realise compiling is better. Microsoft
> >> >is the exception - they tried and failed badly, anyone remember their
> >> >Fortran compiler for the PC. When it compiled without falling over you
> >> >were amazed. When you ran the results you were sorry!
> >>
> >> OTOH, their DOS Basic compilers were fantastic.
> 
> I believe John is incorrect if he is saying as it appears that any
> code which has a decission tree is interpretive.  Interpretive
> languages vs compiled has nothing to do with the logic of the code.
> The point is that compiled (true compiled not pcode) languages are
> already in binary form and so executable directly while each line of
> an interpretive language is converted to binary, each time it is
> executed.  Four calls to the BASIC print function results in for
> "compiles" at run time.  Four calls to printf in C results in one
> compile at compile time and no compiles at run time.  The difference
> is not trivial in terms of speed of execution.  Note that the printf
> function is a bad example as it carries more overhead than most C
> functions.
> Jack