Newsgroups: alt.os.multics,alt.sys.pdp10,alt.folklore.computers,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!news.alpha.net!uwm.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!ix.netcom.com!netcom.com!vsocci
From: vsocci@netcom.com (Vance Socci)
Subject: Re: Retro-Computing!
Message-ID: <vsocciD6KrnM.DxC@netcom.com>
Sender: vsocci@netcom17.netcom.com
Organization: Vcc Technical Services
X-Newsreader: News Xpress Version 1.0 Beta #2.1
References: <massagja-0304950924350001@sprawl.byu.edu> <D6HILL.GAJ@bonkers.taronga.com> <vsocciD6IuJ9.46J@netcom.com> <3luf4e$g9e@lyra.csx.cam.ac.uk>
Date: Wed, 5 Apr 1995 15:39:09 GMT
Lines: 139

dpg1001@cam.ac.uk (Duncan Grisby) wrote:

>
>I've used LabVIEW, and intensely disliked most of it.
>
>[...]
>>Again: if typewriter languages were so great, why don't people design
>>hardware with them instead of using diagrams? Why not just try to come
>>up with text-formulas to describe the shape of a design instead of
>>using
>>a CAD package?
>
>I see this as the main problem with the entire LabVIEW concept -
>it makes software design very similar to hardware design. That's
>not necessarily a bad thing, except that it brings all of the
>difficulties of hardware design with it. While designing a highly
>complex test system using LabVIEW, I found that I was spending around
>10% of my time working out what I needed to do, and the other 90%
>laying out the pretty icons and wiring them up.
>

This is a real problem at this stage of development. I think some
automated, localized cleanup mechanisms which wouldn't globally
scramble the diagrams would help a lot.

>Similarly, trying to understand a program created by someone else
>is a painful experience, tracing the wires joining everything up,
>and flicking through all the cases in case blocks and sequence
>statements.
>

If they used enough comments and managed to lay out the diagrams
correctly, it would help quite a bit. Just like with linear text coding,
uncommented and sloppy code is a nightmare to deal with. No language will
ever completely solve that problem.

>Many of the layout problems could be improved by providing a zoom
>option, and automatic re-routing of connections; a significant
>proportion of my development time was taken up laboriously moving
>bits of my diagrams around so that I could fit one or two extra
>things in.
>
Here here! I agree.

>However, there are limits to how much support the system could
>give towards diagram layout. Firsly, such layout procedures are
>fundamentally "hard" computer science problems requiring huge
>amounts of time for complex diagrams. Secondly, even if there
>was some wonderful "make my diagram nice and neat" function,
>you'd spend the next hour after using it trying to find out
>where it had put all the bits of your diagram.
>

Yes, you'd have to limit its actions in stages somehow or else you could
lose the advantage that spatial memory gives you in a graphical language.

>[...]
>>Code in any langauge is just that: an encoding of the solution to a
>>problem
>>heavily biased towards the engine which will execute the code. Our
>>languages
>>look like they do because our machines are linear, and no one seems to
>>have
>>the imagination and courage (guess I have to include myself in this
>>accusation)
>>to design new architectures and get them to be popular. I'd rather see
>>some languages that are closer to describing the *problem*; then we
>>can
>>generate solutions to the problem based on available
>>"realware"/hardware.
>
>I agree that conventional linear programming is highly
>restrictive, and we could benefit from less linear programming
>methods. I don't think LabVIEW's approach is the correct one,
>however. A programming environment making use of a GUI to allow
>concurrent activities to be coded in a linear manner, in separate
>but interlinked windows, would provide many of the good points
>of LabVIEW, while leaving out most of the painful layout problems.
>As I previously mentioned, I think that LabVIEW's user interface
>design facilities are excellent, and would be wonderful if
>coupled with a less irritating programming method.
>

You could program all or most of the VIs in C and use LabView
to link them together. That would achieve what you are looking for to a large
degree. They'd probably have to make it easier to connect the C modules
to LabView though to retain the ease of use that the system currently has.

>
>I think that LabVIEW is ideal for people who have not programmed
>before who need to create programs for simple instrumentation
>and data logging requirements. On the other hand, I believe it is
>entirely unsuitable for the sort of large scale testing application
>I was using it to develop.
>

I also developed a large scale testing application using LabView. In fact,
it was originally written by someone at National Instruments, and I had
to clean it up and write new pieces of it. It was written fairly well, so
it wasn't too painful to grok the diagrams. It had automatic restart (checkpointed
its state on the disk) and lots of advanced features. I don't think the language made it
any more difficult to express the solution, but its hard to really say.

At the time, this was about the largest application ever attempted in LabView.
The original designer forgot to interlock her common database and had all sorts
of horrible bugs. I had to implement a couple of kinds of interlocks (reminded
me of TOPS10!!) to get the code to work properly. The testing was extremely
long term (months) so it had to be totally reliable.

I've done four or five other major data aquisition applications in LabView, and
I found that LabView worked in my favor. One was a fairly simple, typical
simple data aquisition program, but some of the others were not.

Its a new kind of language; it is reasonable to expect to use it a few times to
develop your coding techniques, just like any other language.

>
>Duncan.
>
>--
> -- Duncan Grisby                                    --
>  -- dpg1001@cam.ac.uk                                --
>   -- finger dpg1001@cus.cam.ac.uk for PGP public key. --

Enjoyed your comments, its nice to hear from someone that's used the thing,
even if your experience wasn't as positive as mine. (I did present the LabView
developers with a 15 page paper on ways I thought they had to improve the
language, so I don't think its perfect by any means).



- Vance

/=======================================\
|    Vance Socci   vsocci@netcom.com	|
| "The worst secrets are those we keep	|
|   from ourselves . . ."		|
| "I am not a number; I am a free man!	|
\=======================================/
