Re: Stop making unneeded improvements

[Marcus D. Leech]

On 01/07/2021 03:32 PM, paul@dbnut.com wrote:

Prompted to write by Glen Langston's post, I'm an old man resurrecting an old moan, and in a minority that (I believe) is just not catered for:

* Windows user
* Non-programmer (of any great consequence)

It was NEVER a goal of GR to make it easy for those without skills in programming, radio, and DSP to be successful despite those
  handicaps.  There has been a growing perception that GR is "just a radio with a lot of knobs".  It isn't.  It's a programming
  environment for a highly-specialized discipline, notably signal processing.   GRC has had the unfortunate side-effect of making
  GR seem like "a radio with a lot of knobs", and certainly if that's your perception of what GR is, then GRC will fall fare short of that goal.

If you expect to be brilliantly successful despite a lack of the requisite skills, and blame the *tools* for your lack of success, then you
  should perhaps take a breath and re-think your position.   I liken this attitude to some rich fool buying an A320, taking himself and
  his closest friends up in it for a maiden flight, only to be disappointed that he and his friends are now all dead, because they couldn't
  be bothered to learn how to be a pilot, study theory-of-flight, avionics, navigation, etc, etc, etc.  But that's clearly the tools fault, right?

Let's you think I'm some young punk, I'll be 60 in a couple of years.  That makes me, decidedly, an "old fart" in this game.

A couple of years ago I became hooked on GRC after watching Balint Seeber's YouTube videos that convinced me this was a great non-programming solution to a long-standing problem of mine.

You clearly mis-understood what you were seeing.   GRC has this unfortunate side-effect.  Could GRC be "better" (for whatever value
  of "better" you want to use)?  Of course.  But don't think for a moment that you'll ever get around the fact that you'll need to understand
' what you're doing, both in terms of DSP knowledge and programming knowledge and experience.  That's not what GR is, and I'd
  challenge you to find ANY tool in a deeply technical field like signal processing that removes the need to understand what you're
  doing, and why.    But if you're at the level of "why should I need to understand what roles filters play, what sample-rates imply,
  how demodulators work" then you should look elsewhere.  You'll be looking for a very long time.

Another proximate example.  There are now lots of really awesome tools that neurosurgeons use to help them do their jobs.
  But not a single one of those neurosurgeons go into that operating room without any understanding of anatomy, neurology,
  neuro-pharmacology, and years and years of experience as an intern.  They don't simply waltz in there, turn on the
  "Surgeons Assistant 5000" device, and push the "cure my patient" button.

True, after 6 months I managed to fumble my way to a flowgraph that sort-of got the job done. But there were serious limitations, such as WX widget deficiencies including only mono audio stream for some sources/sinks (just how out-of-date can you be in the 21st century?).
So I tried to migrate to QT, and what happens? Every one of the replacement widgets looks and behaves differently from its predecessor and, in several cases, has significantly reduced functionality.

I'll point out that GR is, at its core, just a set of library functions, a buffer manager, and a thread scheduler. There is ABSOLUTELY NO REQUIREMENT
  to use the facilities of GRC, and no requirement to use its world-view of the GUI widgets.  GQRX is one example out there, and I myself
  built a fairly-complex GR-based application using the XForms toolkit years and years ago.

Add in inexplicable control gaps like decade "thumb-wheels" (for tuning) or command buttons (e.g. to increment a variable by a preset amount) and it's clear that Gnu Radio Companion fails to replicate anything like a basic RADIO front panel.

Because GR isn't as I've pointed out, "just a big radio with a lot of knobs".   BTW sliders can be used and configured for whatever increment and
  range you want--and, again, you are not constrained to use any particular GUI toolkit with GR.    GRCs GUI toolkit was largely initially imagined
  as a way of having some debugging tooling lying around, and not necessarily to produce a "gorgeous radio front-panel".  That it has *just*
  enough functionality to convince you that it is heading for the "gorgeous radio front-panel" direction, rather than the "help me debug my
  application" direction can certainly lead you to find it seriously wanting.  But, again, nothing requires that you use GRC or its particular
  set of widgets.

I won't even start moaning about changes to Python versions and libraries.
What kind of a development strategy is that? It's no excuse that you rely on a team of volunteers. If you want quality you need leadership, direction and team players - every programmer following his own whim to produce "cool stuff" on his own agenda is a recipe for disaster. I've been a "volunteer" myself for 15 years, trying to put something back into the radio community I love, with never a cent in return, and don't do "cool stuff".

On the other hand, do you expect GR to just remain static in the face of underlying *critical* dependencies like Python changing underneath?
  How would you propose to make that "easy" when GR finds itself on a platform that may no longer have Python2.7, for example?  Or
  wildly-deprecated WX libraries?  Modern software has dependencies on other software.  That's just a fact of life.  You can argue that
  the software (GR in this case) shouldn't have any dependencies, but then you'd find that GR offered very few features, and it would bring
  out new versions roughly every 10 years, because all of the "goo" that is currently based on third-party libraries is now in-skin, and
  desperately hard to maintain.  GR is nowhere-near unique in having this problem.  Every piece of Open Source feature-rich software has
  this problem--it can either rely on 3rd-party libraries underneath, and thus have to make difficult management decisions from time-to-time,
  or it can simply do *everything* "in skin", and suffer the even worse consequences.    The dependency "hell" is made even worse by the
  fact that Linux has been wildly successful.  So much so that if you're an application developer, you have almost no way of predicting
  how your software will be configured and installed on any given version of Linux, from which there are dozens to choose from--each with
  their own package-management systems, choices of system libraries, system-management functions, network stacks, etc, etc.  When a
  user runs into a problem installing your software on Linux-variant-47, you, as a developer, may have little to no "magic bullets" to make
  that process easier, because that process is entirely out of your control.   That can definitely exacerbate the negative "user experience",
  but a project like GR has very little control over that experience.   If you don't like the way your particular Linux distro has packaged GR,
  then your first line of complaint should be to whoever maintains that distro.

BTW under "cool stuff", I include the disgraceful self-promotion and waste of valuable time in the YouTube video https://www.youtube.com/watch?v=bHjITd2HR-g&ab_channel=GNURadio.

The golden rules for development include doing the basics well, backwards compatibility, not breaking what already works, incremental improvement, giving priority to fixing bugs/defects, and testing, testing, testing. GRC has broken all of these big time over the years.
If during my working life I had been so cavalier in my attitude, I would have lost my job many times over.

"Things breaking" is just a fact of life in software development.  I worked in commercial software dev for nearly 40 years.  Open source
  projects are sometimes a bit worse in this regard because:

o  They get ambitious
o  They rely on other open-source tool-kits, which can break
o  They may not get as much free QA bandwidth as free developer bandwidth
o  They nearly never get any free technical-writer bandwidth

I suppose the real problem (for me) is that GRC is written by DSP experts for DSP students who get by with a little help from their friends, adding a bit of Python here and C++ there. In other words, GRC is *not* the general purpose learner's tool that comes across in the Balint intro.

One could, I suppose, crack open a good book on DSP and programming techniques.  When I first started programming in C in 1979,
  I was not at all aghast at the fact that the C compiler didn't, in fact, include a complete 4-year undergraduate course in computer
  science.  When I made mistakes, when I actually had to apply myself to programming problems, I took responsibility for those problems,
  and became a not-entirely-unaccomplished software developer as a result.   When I first started using a lathe 20 years ago, I didn't
  blame the machine for my lack of skill.  There was no "clippy" who popped up and said "looks like you're trying to make a bronze bearing--
  would you like me to do it for you?".

As for the lack of support for Windows, how can you possibly ignore (more-or-less) the No. 1 operating system with its large pool of users hungry for GRC-type tools? If your fundamentalist fixation on *nix prohibits contact with the unclean, please have the honesty to label your product accordingly.

90% of the volunteer contributors to GR are *nix developers.  We cannot force those to become Windows developers.  There's no
  paycheque-linked carrot dangling in front of them to do that.  GR has *never* excluded anyone from contributing in its 16 year
  history.  That there are very few Windows people contributing is not due to a conscious effort on the part of the many generations
  of GR project management.  If people want to make the GR experience better on Windows, they are welcome to contribute.  They
  always have been.

People like Geof Nieboer have done much over the years to make GR easier to install on Windows.  The project needs more like that,
  but cannot make them appear out of thin air.

I repeat my acceptance of being in a minority, apologise too for the rant, and realise it will not make any difference. But best wishes for the future.

Paul White