Frank,

Although you're an accomplished programmer of many years standing and I'm
just a dabbler, I'd like to say from a users perspective: -

1. Aren't the relative benefits of graphical programming versus text based
programming down to what you prefer to work with? Look at the rise in
popularity and power of LabView - e.g. used by NASA for control of quite a
few deep space missions. Many people who have to get results fast say they
prefer it because of the head start it gives them and the speed of
development. It doesn't come without some performance penalties I would
guess, though.

2. Text based programming has been around even longer than graphical
programming. I'd say that was pretty 'old' too ;-). I was intrigued by the
Synthedit project because it was (a) low cost (b) popular (c) an open
system capable of modular expansion by relatively unskilled programmers.

3. If not enough thought was put into the modules that made up the
graphical palette - then I agree - the system would rapidly start to feel
'old' - by which I infer limited in potential or prone to go obsolete.

4. On the other hand - (I run a small EMC test lab) - I use a specialised
graphical programming language called TILE to create test programs to
control the instruments in our lab. It amazes me how versatile the system
is in meeting new challenges, despite the fact it has such a small icon
palette (about 20 modules). I can use the same old hardware in so many
different ways I couldn't do with the closed system we had before. The 20
modules together with the ability to do math, create graphs and tables
provides a very flexible control and measurement system.

5. The great thing about a graphical programming language - albeit only if
structured well - is that the program can be essentially self-documenting
and extremely modular. You can glance at a flowchart and get the gist of
the data flow and overall purpose - which is not the case with a page of
text program language. PowerSDR source presently has very little comment
and no top-level specification to guide the stranger into the project -
understandably, given the constraints you guys are working under.

I'll be very interested to see where the  SDR1000 control software
development goes next - the above is just the hankering of an enthusiast to
open the radio up to more people like myself who aren't advanced
programmers. If the Python system gave us the transparency that is needed
in terms of data flow and relatively short learning curve, then I'm all for
it - despite it being text based ;-)

I'm very happy as a radio operator with PowerSDR as it stands  - the above
is just constructive criticism by a hardware engineer that wishes he could
contribute more to the project.

Keep it up and best regards, Bob G4BBY



Reply via email to