[SciPy-Dev] Python Scipy Block Diagram Editor with ACG

dwight reid dreid@dwightreid....
Wed Nov 21 16:56:51 CST 2012


Guys,
I think graphical programming is more appreciated by people who are not traditional programmers but who have to use programming as a tool to get a bigger job done. A common example is control system development, like for an aircraft. Simulink got popular because it allows the designer to model the dynamics of the system with generic blocks, simulate that system and then design and tweak a controller to work with the system. So it allows simulating the system the way you would do a circuit in a good spice simulator and with code generation you can then implement your final controller with the click of a button (somewhat). 

Its a powerful tool and obviously engineers love it. The block diagram seems to make it easier to understand what the program is doing and we must note that most new designs start as block diagrams anyway.

As we know there are good ways and bad ways of doing things, a text based code can be just as impossible to debug if it is not documented properly as a complicated block diagram.

DR




________________________________
 From: Matthias BUSSONNIER <bussonniermatthias@gmail.com>
To: SciPy Developers List <scipy-dev@scipy.org> 
Sent: Wednesday, November 21, 2012 1:43 PM
Subject: Re: [SciPy-Dev] Python Scipy Block Diagram Editor with ACG
 

Hi list, 

Le 21 nov. 2012 à 17:21, Eraldo Pomponi a écrit :

AFAIK the best example of visual programming/interaction is LabView (http://www.ni.com/labview/). 
>
>I agree that many scientist don't like it but it is really widely adopted not just for control theory and application. 
>It was also the subject of a "Patent Litigation" between MatWorks (Simulink) and NI (http://www.ni.com/pdf/products/us/patent_litigation_faq.pdf)......
>Ni won! 
>I think that it shows pretty much cleanly that complex projects can be managed completely graphically if  the environment is enough mature for that. 
>
>LabView seems to meet that requirement. Of course it is NOT open. This is why I do not use it. 


It is not because something is widely adopted that it is well used, and does its job.
In this case it does not prove that Labview allow to managed correctly things,
at best that people achieve to (sort of) work with that.

To be working in a lab that does use labview and to be forced to use it, 
one of the main reason lab view is used it because it comes with drivers for instrument, 
and support that goes with it.

The others being:
  *  it is already use by others nearby scientist.
  *  scientist think do not know how to program,
  *  they need a visual interface fast
  * The lab have already paid for the license you better have to use it.


We use labview for are optical tweezer and microscope control, which is a pretty big piece of software in labview.
The code exist for years, when I arrived each files had a v0.1, v0.1.1….v0.9-bis, first file was 4 year old.
The working copy was the v0.8-smth. The way labview is made we have to copy and past things all around,
have global variable, it is not unit tested.
We all know theses are good programming practice BTW.

For versioning system .vi files are binary blob (800 kb diff to just move a wire so that it avoid a text label ??? )
So no way to know what modification have been made except trusting the commit message. 

I had to throw away 2 month of data / 2 month of lab view coding because one commit was introducing a bug, 
and there was no way to remove just the effect of this commit.

I suppose most of these problem could be fixed in some non trivial way, but they are not in labview.

As a Scientist and a Programmer IMHO the project is not managed in any way. 
And I don't see how one can really manage a project in labview.

A good managed project should be easily 
  * shared, 
  * explained 
  * reusable by other (other can be me in 3 years),

And right now, no labview project I know of have survived their creator / been modified by others. 
Which is really scary in an era of reproducible science.

The others things that concern me is the inability to search for help.

Question/anwser are made of **screenshot**. 
You don't even know what the boxes are and what they do, they don't have name. 
You don't know in which submenu to get them. 
Boxes can have several representation.
Sometime boxes change appearance when you change an option in it !

Inability to search for help is also due to that fact that as things don't have name, 
you can't search for it, and everyone is reinventing its naming.

All that and other make me think that labview is not good for complex project.

I hope those are issues that can be solved by people that are trying to do the same,
but some of those are IMHO inherent to the graphical paradigm used.
Rapidly, crossing wires are unavoidable in 2d space for example.

As a bonus, that also highlight another problem.
Try to guess what this simplified snippet does
http://imgur.com/PEgeq,n47uH#1  
http://imgur.com/PEgeq,n47uH#0 (condition of the if statement set to true)

It also allow people that does not know labview to understand what it looks like.

Solution in  rot13 : 
Vg gel gb perngr svyr jvgu tvira anzr, vs fhpu n svyr rkvfg vg vaperzragf gur anzr ...
Qvq fbzrobql frr gur raq bs gur sbe ybbc ng gur obggbz bs gur fperrafubg ?

TL;DR: 
  I think Labview Sucks, I hope other FlowPrograming will find a way to correct It, I wish them Luck.

-- 
Matthias




>
>Cheers,
>Eraldo 
>
>
>
>
>
>
>
>On Wed, Nov 21, 2012 at 4:48 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
>
>
>>
>>
>>On Wed, Nov 21, 2012 at 8:01 AM, Neal Becker <ndbecker2@gmail.com> wrote:
>>
>>Charles R Harris wrote:
>>>
>>>> On Tue, Nov 20, 2012 at 11:41 AM, Cera, Tim <tim@cerazone.net> wrote:
>>>>
>>>>>
>>>>> As is, the block diagram editing is done in libre office draw and you have
>>>>>> to manually type in the functions and commands, I have
>>>>>> attached an example exported to pdf.
>>>>>
>>>>>
>>>>>
>>>>> Would anyone be willing to help with this, I have no experience developing
>>>>>> with the open source community.
>>>>>>
>>>>>
>>>>> I won't be able to help, except to give some information.  Found this
>>>>> http://wiki.python.org/moin/FlowBasedProgramming a long time ago which
>>>>> might be useful.  Some of the links are broken now, and some of the others
>>>>> are really old, but something there might be helpful.
>>>>>
>>>>> In general, flow based programming hasn't caught on.   I think partially
>>>>> because of reasons described in the old saying, "To hell with tradition, we
>>>>> are going to do it like we always did!"
>>>>>
>>>>>
>>>> Simulink is pretty widely used, especially for modelling and rapid
>>>> development of control software.  Equipment vendors provide blocks for
>>>> their devices, gyroscopes and such, that can be used for the models and
>>>> then Matlab will generate control code to run on the targeted system.
>>>> Simulink itself is basically a way of setting up a big system of DEs, but
>>>> what really makes it go are the vendor blocks and code generation.
>>>>
>>>> Chuck
>>>
>>>So why would vlsi guys use text (e.g., verilog) to design a cpu, instead of
>>>schematics?
>>>
>>>1. IMO, graphical representations work nicely for low-complexity, but not
>>>productive for highly complex systems
>>>
>>>2. It is less productive to manipulate a graphical  representation
>>>
>>>3. text can be manipulated by all your favorite tools, more open ecosystem, no
>>>lockin, proprietary formats
>>>
>>>
>>>
>>
>>I'm not saying it's the best way, just that Simulink is widely used and is part of a mature ecosystem. FPGA design software, say Xilinx ISE, does have a visual front end, generally in tabular form. In that regard it is rather like gui design tools where objects can be opened and their attributes set. I think the thing that makes all of those tools go is code generation, the ability run simulations, and to insert probes that display values in graphical form as the simulation progresses. IIRC, Simulink can also be used to drive hardware for breadboarding designs.
>>
>>Chuck  
>>
>>
>>_______________________________________________
>>SciPy-Dev mailing list
>>SciPy-Dev@scipy.org
>>http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
>
_______________________________________________
>SciPy-Dev mailing list
>SciPy-Dev@scipy.org
>http://mail.scipy.org/mailman/listinfo/scipy-dev
>

_______________________________________________
SciPy-Dev mailing list
SciPy-Dev@scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/scipy-dev/attachments/20121121/2114e490/attachment-0001.html 


More information about the SciPy-Dev mailing list