[FRPythoneers] Re: VB/Python article....

J. Wayde Allen wallen at its.bldrdoc.gov
Wed Jun 6 09:32:23 MDT 2001

On Tue, 5 Jun 2001, Ferdinand Schmid wrote:

> - However you turn it I always prefer "drawing" a GUI to coding it by
> hand.  I have a hard time visualizing what the GUI will look like based
> on sets of coordinates...

I have to agree that the ability to more or less draw the GUI is
useful.  The GUI is in a sense a piece of "graphic art" and as such it
makes sense to approach it graphically rather than programatically.

> The engineer who writes little VB applications for
> her/his personal or departmental use don't know much about programming
> nor do they care about style.  They just want to get a small job done
> with minimal computing knowledge and personal effort.

This is certainly true.

> VB gives them a tool to do this and Python still isn't simple enough
> for this group of users.

It probably depends on the group of engineers and the task at hand.  Most
engineers I'm around these days have little patience for VB or any
language that they perceive as being textual.  The current rage in the our
Labs is National Intruments Labview
<http://digital.ni.com/productpages/nilabview.nsf/main?readform>.  This
system takes the graphical idea even further.  In our environement,
getting people to use VB is difficult, so trying to get them to use Python
is extremely problematic.

> Most of this little utilities have GUIs for one reason or another.

Yes, but quite often I wondery why?  Many of these quick-and-dirty
applications have no real need for a GUI.  Funny how the GUI has become
more important in many cases than the task that prompted the development
of the program.

> Python could become a perfect match for this type user due to
> is capabilities for handling complex math (complex nubers...) once it
> makes the switch from VB easy.

Ah yes, complex numbers and a good set of numerical computational
routines.  Not to mention interactive programming capability, a simple
object oriented programing model, and cross platform capability.  These
are all things that make Python interesting as a laboratory tool.

One problem though, is that there are two levels of Scientific
programmers.  Those doing the high level simulations (Finite Elements,
Finite Difference Time Domain, etc.) automatically will choose a language
that gives them the greatest computational power and the fastest
performance.  Not too surprisingly many of these kinds of software
packages are written in Fortran.  It is somewhat unlikely that Python
will break in here.

I think the more likely place for the application of Python in the
scientific community is in the data acquisition and processing
arena.  This is where we need to rapidly construct measurement routines,
and easily manipulate small to moderately large sets of data.  Speed isn't
the issue here so much as useability.  The old standard language for this
was Hewlett Packard's Rocky Mountain Basic.  Mostly since the HP computers
were very reliable, and the commands needed to control instrumentation via
the IEEE4888 instrument control bus were built in.  With the proliferation
of the Windows box into this arena we now have:

   HTBasic             - Transera's version of Rocky Mountain Basic
   HPBasic for Windows - HP's new version of Rocky Mountain Basic
   HPVEE               - HP's graphical programming environment
   Labview             - National Instruments graphical environment

Visual Basic sort of fits, but not real well.  People well steeped in
HPBasic seem to have an aversion to it, although I'm not too sure
why.  In part, VB is not surprisingly targeted more at the business side
of things.

Python has many advantages, but suffers from:

   - Its a new language to learn
   - Many people have never heard of it
   - Legacy code written in HPBasic has to be re-coded
   - Not obviously graphical (so loses to VB, and Labview)
   - Not clear that instrument control is easy to do in Python

> If you want to introduce a popular tool then it needs to be simple
> enough for just about anybody to use.

This is a necessary but not sufficient condition.

>  Windows and Plug&Play brought PCs to the masses, not DOS or Unix.  

I actually wonder about this?  We'll never know, but I'm not too sure that
MSWindows brought computing to the masses.  It's graphical displays may
have helped, but the so-called standard look and feel had already emerged
before windows took the field.  Many DOS programs already had menu bars,
etc..  I think the entire phenomonon may have been more a case of critical
mass.  The business community had already started to use computers and I
think that this trend would have continued whether we had Windows or
not.  Perhaps the computer game is what really made the home computer more
common and approachable?

> If Python's goal is to be useful to a fairly small group of skilled and
> well educated programmers then IDEs aren't necessary.  If its goal is to
> take the place of VB and similar tools then it needs to offer a similar
> level of ease of use to beginners.
> Just my opinion from the front between software development and
> engineering.

Yes, in most ways we agree.

- Wayde
  (wallen at its.bldrdoc.gov)

More information about the FRPythoneers mailing list